AI/ML Rel-19

RAN1#116

9.1 Artificial Intelligence (AI)/Machine Learning (ML) for NR Air Interface

Please refer to RP-234039 for detailed scope of the WI.

R1-2401766 Session notes for 9.1 (AI/ML for NR Air Interface) Ad-Hoc Chair (CMCC)

Friday decision: The session notes are endorsed and contents reflected below.

[116-R19-AI/ML] – Taesang (Qualcomm)

Email discussion on Rel-19 AI/ML

- To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc

R1-2401430 Work plan for Rel-19 WI on AI and ML for NR air interface Qualcomm Incorporated

9.1.1 Specification support for beam management

R1-2400045 Discussion on AIML for beam management Spreadtrum Communications

R1-2400144 Discussion on beam management for AI/ML Huawei, HiSilicon

R1-2400171 AI/ML for beam management Ericsson

R1-2400232 Specification support for beam management vivo

R1-2400263 Discussion on specification support for AI/ML beam management ZTE

R1-2400274 Specification Support for AI/ML beam management TCL

R1-2400316 Discussion on specification support for beam management CMCC

R1-2400376 Specification support for AI/ML for beam management Intel Corporation

R1-2400392 AI/ML based Beam Management Google

R1-2400418 Discussion on AI/ML-based beam management CATT

R1-2400465 Discussion on specification support for beam management NEC

R1-2400543 Specification support for beam management xiaomi

R1-2400618 On specification for AI/ML-based beam management OPPO

R1-2400683 Discussion on AI/ML for beam management InterDigital, Inc.

R1-2400692 Specification support for AI-enabled beam management NVIDIA

R1-2400720 Discussion for supporting AI/ML based beam management Samsung

R1-2400766 Discussion on specification support on AI/ML for beam management Fujitsu

R1-2400781 Discussion on specification support for AI/ML-based beam management FUTUREWEI

R1-2400793 AI/ML for Beam Management Nokia, Nokia Shanghai Bell

R1-2400831 AI/ML specification support for beam management Lenovo

R1-2400844 Discussions on AI/ML for beam management Sony

R1-2400895 Prediction of untransmitted beams in a UE-side AI-ML model Rakuten Mobile, Inc

R1-2400907 Specification support for beam management Fraunhofer HHI, Fraunhofer IIS

R1-2400914 Discussions on AI/ML for beam management LG Electronics

R1-2401002 Discussion on AI/ML beam management Apple

R1-2401043 Discussion on AI/ML based beam management Hyundai Motor Company

R1-2401475 Discussion on specification support for beam management NTPU (rev of R1-2401055)

R1-2401107 Discussion on AI/ML for beam management NTT DOCOMO, INC.

R1-2401134 Discussions on AI/ML for beam management CAICT

R1-2401136 Specification support for beam management KDDI Corporation

R1-2401153 Discussion on Specification Support of AI/ML for Beam Management Indian Institute of Tech (M), IIT Kanpur

R1-2401161 Considerations on AI/ML based beam management KT Corp.

R1-2401171 Discussions on specification support for beam management Sharp

R1-2401179 Discussion on support for AI/ML beam management ITL

R1-2401223 Discussion on specification support for beam management ETRI

R1-2401267 Discussion on Specification Support for Beam Management CEWiT

R1-2401297 AI/ML - Specification support for beam management MediaTek Inc.

R1-2401431 Specification support for AI-ML-based beam management Qualcomm Incorporated

R1-2401596 FL summary #0 for AI/ML in management Moderator (Sumsung)

Presented in Monday session.

R1-2401597 FL summary #1 for AI/ML in management Moderator (Samsung)

Presented in Tuesday session.

R1-2401598 FL summary #2 for AI/ML in management Moderator (Samsung)

From Thursday session

Agreement

For NW-sided model, for inference, in a beam report initiated by network, based on one measurement resource set, support the report of more than 4 beam related information in L1 signaling

· Note: Purpose, such as above “For NW-sided model, for inference”, will not be specified in RAN 1 specifications

· FFS on the report content for beam related information

· FFS on max number of reported beam related information in one report

Agreement

For UE-sided model, at least for BM-Case1, for content in the report of inference results, support

Opt 1: Beam information on predicted Top K beam(s) among a set of beams
Opt 2: Beam information on predicted Top K beam(s) among a set of beams and RSRP of predicted Top K beam(s) among a set of beams
At least K=1 and more, FFS on max value
FFS on beam information
FFS on the definition of predicted Top K beam(s)
FFS on definition of reported RSRP when applicable
FFS on other information in the report with potential down selection among the following options

Opt 3: Beam information on predicted Top K beam(s) among a set of beams and probability information of predicted Top K beam(s) among a set of beams

FFS on the quantization method of probability information
Probability information is the probability of the beam to be the Top 1 or Top K beam

Opt 4: Beam information on predicted Top K beam(s) among a set of beams, RSRP of predicted Top K beam(s) among a set of beams, and confidence information of the RSRP

FFS on definition of reported RSRP
FFS on the definition and quantization method of confidence information

Other options are not precluded.

where the set of beams is Set A, i.e., the beams for UE prediction.

Agreement

For NW-sided model and for UE-sided model, beam indication is based on unified TCI state framework

· FFS on whether/how potential enhancement is needed

Conclusion

For UE sided model at least for inference, for measurement, the configuration of Set B,

· take the current CSI framework as the starting point

Final summary in R1-2401599.

9.1.2 Specification support for positioning accuracy enhancement

R1-2400101 AI/ML for Positioning Accuracy Enhancement Ericsson

R1-2400145 Discussion on positioning accuracy enhancement for AI/ML Huawei, HiSilicon

R1-2400169 Discussion on specification support for AI/ML positioning accuracy enhancement ZTE, Pengcheng laboratory

R1-2400233 Specification support for positioning accuracy enhancement vivo

R1-2400317 Discussion on specification support for positioning accuracy enhancement CMCC

R1-2400348 Discussion on specification support for positioning accuracy enhancement TCL

R1-2401492 Specification support for AI/ML for positioning accuracy enhancement Intel Corporation (rev of R1-2400377)

R1-2400393 AI/ML based Positioning Google

R1-2400419 Discussion on AI/ML-based positioning accuracy enhancement CATT

R1-2400469 Discussion on specification support for AI/ML based positioning accuracy enhancement NEC

R1-2400544 Discussion on AI/ML-based positioning accuracy enhancement xiaomi

R1-2400619 On specification for AI/ML-based positioning accuracy enhancements OPPO

R1-2400693 Specification support for AI-enabled positioning NVIDIA

R1-2400721 Discussion for supporting AI/ML based positioning accuracy enhancement Samsung

R1-2400757 Discussion on AI/ML-based positioning accuracy enhancement CICTCI

R1-2400767 Discussions on specification support for AI/ML positioning accuracy enhancement Fujitsu

R1-2400794 AI/ML for Positioning Accuracy Enhancement Nokia, Nokia Shanghai Bell

R1-2400845 Discussions on AI/ML for positioning accuracy enhancement Sony

R1-2400923 Specification impacts for Enhanced Positioning Lenovo

R1-2401003 Discussion on Specification support for positioning accuracy enhancement Apple

R1-2401042 Discussion on support for AIML positioning InterDigital, Inc.

R1-2401476 Discussion on Support for Positioning Accuracy Enhancement NTPU (rev of R1-2401056)

R1-2401082 Discussion on specification support for AI-ML based positioning accuracy enhancement Baicells

R1-2401108 Discussion on specification support for positioning accuracy enhancement NTT DOCOMO, INC.

R1-2401137 Design for AI/ML based positioning MediaTek Korea Inc.

R1-2401154 Discussion on Specification Support of AI/ML for Positioning Accuracy Enhancement Indian Institute of Tech (M), IIT Kanpur

R1-2401172 Discussions on specification support for positioning accuracy enhancements Sharp

R1-2401198 AI/ML positioning accuracy enhancement Fraunhofer IIS, Fraunhofer HHI

R1-2401268 Discussion on specification support for AI/ML Positioning Accuracy enhancement CEWiT

R1-2401432 Specification support for AI-ML-based positioning accuracy enhancement Qualcomm Incorporated

R1-2401544 Summary #1 of specification support for positioning accuracy enhancement Moderator (Ericsson)

Presented in Monday session.

R1-2401545 Summary #2 of specification support for positioning accuracy enhancement Moderator (Ericsson)

From Tuesday session

Agreement

For Rel-19 AI/ML based positioning, the measurements for determining model input are based on the DL PRS and UL SRS defined in TS38.211.

· Note: The use of SRS for MIMO resource is transparent to UE.

Agreement

For AI/ML based positioning case 3b, at least the following types of time domain channel measurements are supported for reporting:

· timing information;

· paired timing information and power information.

Agreement

For AI/ML based positioning case 2b, at least the following types of time domain channel measurements are supported for UE reporting to LMF:

· timing information;

· paired timing information and power information.

R1-2401546 Summary #3 of specification support for positioning accuracy enhancement Moderator (Ericsson)

From Thursday session

Agreement

In Rel-19 AI/ML based positioning, regarding the time domain channel measurements, RAN1 investigate the following alternatives:

· Alternative (a). Sample-based measurements, where the timing information is an integer multiple of sampling periods.

· Alternative (b). Path-based measurements, where the timing information is according to the detected path timing and may not be an integer multiple of sampling periods.

The issues to be studied include, but not limited to, the following:

· Tradeoff of positioning accuracy and signaling overhead

· Impact and necessary details of gNB/UE implementation to obtain the channel measurement values.

· Whether the same Alternative(s) applies to all cases or not

· Applicability and necessity of specifying the Alternative(s) to different cases

· Note: different sub-cases may have different issues.

Note: In addition to timing information, the components for the channel measurement for model input may also include power and potentially phase. To provide the type of the channel measurement in their investigation.

Agreement

For AI/ML assisted positioning Case 3a, at least LOS/NLOS indicator and/or timing information are supported for reporting.

If LOS/NLOS indicator is reported, the indicator can be reported as soft indicator or hard indicator as defined in 38.214.
If timing information is reported, the timing information at least can be reported via UL RTOA or gNB Rx-Tx time difference as defined in 38.215.
Note: details of the report are pending further discussion.

Agreement

For AI/ML assisted positioning Case 2a, at least LOS/NLOS indicator and/or timing information are supported for reporting.

If LOS/NLOS indicator is reported, the indicator can be reported as soft indicator or hard indicator as defined in 38.214.
If timing information is reported, the timing information at least can be reported via DL RSTD or UE Rx-Tx time difference as defined in 38.215.
Note: details of the report are pending further discussion.

R1-2401825 Summary #4 of specification support for positioning accuracy enhancement Moderator(Ericsson)

From Friday session

Agreement

For LMF-side model, RAN1 studies whether/what assistance information and/or measurement report may be sent from UE/PRU, and/or gNB to LMF to assist at least for the performance monitoring.

RAN1 understands that it is out of RAN1 scope to define monitoring metric calculation and related model management decisions for LMF-side model.

Agreement

For AI/ML based positioning Case 3b, for gNB channel measurements reported to LMF, the timing information is represented relative to a reference time.

FFS: Whether any specification impact of the reference time used to represent the timing information. Details of the reference time

Agreement

For AI/ML based positioning for all use cases, RAN1 investigate the necessity and feasibility of using phase information (in addition to timing information and power information) for determining model input. The issues to study include:

Tradeoff of positioning accuracy and signaling overhead
The impact of transmitter and receiver implementation
Specification impact
Other aspects are not precluded

Note: the phase information may be used in different ways, e.g., one phase value for the first path or first sample only; triplet of {timing information, power information, phase information} for CIR, etc.

9.1.3 Additional study on AI/ML for NR air interface

R1-2400185 Additional study on AI/ML for NR air interface Comba

9.1.3.1 CSI prediction

R1-2400046 Discussion on AIML for CSI prediction Spreadtrum Communications, BUPT

R1-2400146 Discussion on CSI prediction for AI/ML Huawei, HiSilicon

R1-2400165 AI/ML for CSI prediction Ericsson

R1-2400234 Discussion on CSI prediction vivo

R1-2400264 Discussion on study for AI/ML CSI prediction ZTE

R1-2400318 Discussion on AI/ML for CSI prediction CMCC

R1-2400378 AI/ML for CSI compression Intel Corporation

R1-2400394 AI/ML based CSI Prediction Google

R1-2400420 Study on AI/ML-based CSI prediction CATT

R1-2400463 Discussion on CSI prediction NEC

R1-2400545 Discussion on one side AI/ML model based CSI prediction xiaomi

R1-2400620 Additional study on AI/ML-based CSI prediction OPPO

R1-2400656 Discussion on AI/ML-based CSI prediction China Telecom

R1-2400694 Additional study on AI-enabled CSI prediction NVIDIA

R1-2400722 Discussion for further study on AI/ML-based CSI prediction Samsung

R1-2400768 Discussion on CSI prediction with AI/ML Fujitsu

R1-2400795 AI/ML for CSI Prediction Nokia, Nokia Shanghai Bell

R1-2400832 On AI/ML for CSI prediction Lenovo

R1-2400842 Discussion on AI/ML for CSI prediction SK Telecom

R1-2400846 Discussions on CSI prediction Sony

R1-2400896 Varying CSI feedback granularity based on channel conditions Rakuten Mobile, Inc

R1-2400908 Discussion on AI/ML-based CSI prediction InterDigital, Inc.

R1-2400915 Study on CSI prediction LG Electronics

R1-2401004 Discussion on AI based CSI prediction Apple

R1-2401036 Discussion on AI/ML for CSI prediction Panasonic

R1-2401477 Discussion on CSI Prediction under AI/ML for NR Air-Interface NTPU (rev of R1-2401057)

R1-2401109 Discussion on the AI/ML for CSI prediction NTT DOCOMO, INC.

R1-2401151 Discussion on study of AI/ML for CSI prediction IIT Kanpur, Indian Institute of Tech (M)

R1-2401269 Discussion on AI/ML for CSI Prediction CEWiT

R1-2401303 CSI Prediction MediaTek Inc.

R1-2401367 Discussion on AI/ML for CSI prediction AT&T

R1-2401433 Additional study on CSI prediction Qualcomm Incorporated

R1-2401584 Summary #1 of CSI prediction Moderator (LG Electronics)

Presented in Monday session.

R1-2401585 Summary #2 of CSI prediction Moderator (LG Electronics)

From Tuesday session

Agreement

For Rel-19 study on CSI prediction, consider EVM agreed in Rel-18 CSI prediction based on UE-sided model as a starting point.

· FFS on additional assumptions, e.g., channel estimation error, phase discontinuity, CSI-RS periodicity.

· Note: Rel-18 CSI-RS configuration/reporting can be reused.

· Note: additional EVM and corresponding template to collect the results can be updated.

Agreement

For Rel-19 study on CSI prediction, ~~companies are encouraged~~ to evaluate throughput performance by comparing performance with non-AI/ML based CSI prediction.

· R18 eType II doppler codebook is assumed for CSI report for both AI/ML and Non AI/ML prediction.

· Companies to report the assumption for N4, which could be 1, 2, 4, 8.

Note: Non-AI/ML based CSI prediction (Benchmark 2) can include statistical model based CSI prediction (e.g., based on Kalman filter, Wiener filter, Auto-regression).

R1-2401586 Summary #3 of CSI prediction Moderator (LG Electronics)

From Wednesday session

Agreement

For evaluation, to report computational complexity in unit of FLOPs including additional complexity if applicable, e.g., update of filter, and their assumption on non-AI based CSI prediction when performance results are provided.

Conclusion

For the evaluation of the AI/ML based CSI prediction, it is up to companies to choose the modelling method and companies should report if ‘Channel estimation’ and/or ‘phase discontinuity’ is/are considered by companies.

Agreement

For the evaluation of the AI/ML based CSI prediction, consider following CSI-RS configuration

· Periodic: 5 ms periodicity (baseline), 20 ms periodicity (encouraged)

· Aperiodic: Optional, CSI-RS burst with K resources and time interval m slots (based on R18 MIMO eType-II)

Note: Companies to report observation window (number/distance) and prediction window (number/distance between prediction instances/distance from the last observation instance to the 1st prediction instance) on their evaluation.

Conclusion

For Rel-19 study on CSI prediction only, consider UE-sided model only.

R1-2401587 Summary #4 of CSI prediction Moderator (LG Electronics)

From Thursday session

Agreement

· For CSI prediction evaluations, to verify the generalization/scalability performance of an AI/ML model over various configurations, to evaluate one or more of the following aspects:

o Various UE speeds (e.g., 10km/h, 30km/h, 60km/h, 120km/h)

o Various deployment scenarios

o Various carrier frequencies (e.g., 2GHz, 3.5GHz)

o Various frequency granularity assumptions

o Various antenna port numbers (e.g., 32 ports, 16 ports)

· To report the selected configurations for generalization verification

· To report the method to achieve generalization over various configurations and/or to achieve scalability of the AI/ML input/output, including pre-processing, post-processing, etc.

· To report generalization cases where multiple aspects (e.g., combination of above) are involved in one dataset, if adopted.

· To report the performance and requirement (e.g., updating filter parameters, convergence of filter) for non-AI/ML-based CSI prediction to handle the various scenarios/configurations.

Agreement

For the evaluation of AI/ML-based CSI prediction using localized models in Release 19, consider the following options as a starting point to model the spatial correlation in the dataset for a local region:

Option 1: The dataset is derived from UEs dropped within the local region, with spatial consistency modelling as per TR 38.901.

E.g., Dropped in a specific cell or within a specific boundary.

Option 2: By using a scenario/configuration specific to the local region.

E.g., Indoor-outdoor ratio, LOS-NLOS ratio, TXRU mapping, etc.

Note: While modelling the spatial correlation, strive to ensure that the dataset distribution also correctly captures the decorrelation due to temporal variations in the channel. To report methods to generate training and testing dataset.

Final summary in R1-2401588.

9.1.3.2 CSI compression

R1-2400047 Discussion on AIML for CSI compression Spreadtrum Communications, BUPT

R1-2400095 Discussion on potential performance enhancements/overhead reduction with AI/ML-based CSI feedback compression FUTUREWEI

R1-2400150 Discussion on CSI compression for AI/ML Huawei, HiSilicon

R1-2400166 AI/ML for CSI compression Ericsson

R1-2400235 Discussion on CSI compression vivo

R1-2400265 Discussion on study for AI/ML CSI compression ZTE

R1-2400319 Discussion on AI/ML for CSI compression CMCC

R1-2400379 AI/ML for CSI prediction Intel Corporation

R1-2400395 AI/ML based CSI Compression Google

R1-2400421 Study on AI/ML-based CSI compression CATT

R1-2400464 Discussion on CSI compression NEC

R1-2400501 Discussion on AI/ML for CSI compression Comba

R1-2400511 Discussions on the remaining issues for other aspects of AI/ML for CSI compression TCL

R1-2400546 Discussion on two-sided AI/ML model based CSI compression xiaomi

R1-2400621 Additional study on AI/ML-based CSI compression OPPO

R1-2400653 Discussion on CSI compression for AI/ML BJTU

R1-2400657 Discussion on AI/ML-based CSI compression China Telecom

R1-2400695 Additional study on AI-enabled CSI compression NVIDIA

R1-2400723 Discussion for further study on AI/ML-based CSI compression Samsung

R1-2400769 Discussion on CSI compression with AI/ML Fujitsu

R1-2400796 AI/ML for CSI Compression Nokia, Nokia Shanghai Bell

R1-2400833 On AI/ML for CSI compression Lenovo

R1-2400847 Discussions on CSI compression Sony

R1-2400909 Discussion on AI/ML-based CSI compression InterDigital, Inc.

R1-2400916 Study on CSI compression LG Electronics

R1-2401005 Discussion on AI based CSI compression Apple

R1-2401037 Discussion on AI/ML for CSI compression Panasonic

R1-2401478 Discussion on AI/ML-based CSI compression NTPU (rev of R1-2401058)

R1-2401110 Discussion on the AI/ML for CSI compression NTT DOCOMO, INC.

R1-2401135 Discussions on AI/ML for CSI feedback CAICT

R1-2401152 Discussion on study of AI/ML for CSI compression IIT Kanpur, Indian Institute of Tech (M)

R1-2401155 Discussion on Additional Study of AI/ML for CSI Compression Indian Institute of Tech (M), IIT Kanpur

R1-2401174 Discussions on CSI compression Sharp

R1-2401224 Discussion on AI/ML for CSI compression ETRI

R1-2401242 Discussion on AI/ML for CSI Compression Fraunhofer IIS, Fraunhofer HHI

R1-2401270 Discussion on AI/ML for CSI Compression CEWiT

R1-2401304 CSI Compression MediaTek Inc.

R1-2401339 Discussion on AI/ML based CSI compression ITL

R1-2401434 Additional study on CSI compression Qualcomm Incorporated

R1-2401557 Summary#1 for Additional study on AI/ML for NR air interface: CSI compression Moderator (Qualcomm)

Presented in Monday session.

R1-2401558 Summary#2 for Additional study on AI/ML for NR air interface: CSI compression Moderator (Qualcomm)

From Tuesday session

Agreement

For the evaluation of temporal domain aspects of AI/ML-based CSI compression using two-sided model in Release 19, adopt the following categorization for study:

Case	Target CSI slot(s)	Whether ~~CSI generation part~~ the UE uses past CSI information	Whether ~~CSI reconstruction part~~ the network uses past CSI information
0	Present slot	No	No
1	Present slot	Yes	No
2	Present slot	Yes	Yes
3	Future slot(s)	Yes	No
4	Future slot(s)	Yes	Yes
5	Present slot	No	Yes

Note 1: For the UE ~~CSI generation part~~, the past CSI information may include past model inputs and/or any information derived from them. For the network ~~CSI reconstruction part~~, the past CSI information may include past CSI feedback instances and/or any information derived from them.

Note 2: For case 3 and case 4, ~~the CSI generation model at~~ the UE may perform prediction as a separate step or jointly with compression. Similarly, ~~the CSI reconstruction model at~~ the ~~gNB~~ network may perform prediction as a separate step or jointly with reconstruction. Companies to report which option is selected, the number of future slots, and whether the prediction is AI/ML-based or not.

Note 3: “Target CSI slot(s)” refers to the slot(s) to which the CSI feedback in the report corresponds. “Present slot” refers to the slot of the most recent CSI-RS measurement used to generate the CSI report. “Future slot(s)” includes at least one slot after the present slot and may include the present slot as well.

Note 4: Down-selection is not precluded.

Agreement

For the evaluation of temporal domain aspects of AI/ML-based CSI compression using two-sided model in Release 19, adopt the following as baseline options for UE distribution:

· Option 1: 80% indoor, 20% outdoor

· Option 2: 100% outdoor

Note: Indoor speed is 3 km/h, outdoor speed is chosen from the following options: 10 km/h, 20 km/h, 30 km/h, 60 km/h, 120 km/h. Assumption on O2I car penetration loss and spatial consistency follow the R18 AI based CSI prediction.

Working Assumption

For the evaluation of temporal domain aspects of AI/ML-based CSI compression using two-sided model in Release 19, adopt the following benchmark scheme for performance comparison:

· For cases without prediction of future CSI, use the same benchmark scheme assumed in R18 AI/ML-based CSI compression study.

· For cases with prediction of future CSI, use the same benchmark scheme assumed in R18 AI/ML-based CSI prediction study, with R18 MIMO eType II codebook for compressing the feedback.

R1-2401559 Summary#3 for Additional study on AI/ML for NR air interface: CSI compression Moderator (Qualcomm)

From Wednesday session

Agreement

For the evaluation of AI/ML-based CSI compression using localized models in Release 19, study the following aspects of the performance/complexity trade-off when comparing the localized model with a benchmark model that is not localized:

· Performance of the localized model that has similar or lower complexity as the benchmark model.

· Model complexity of the localized model that achieves similar or better performance as the benchmark model.

Agreement

For the evaluation of temporal domain aspects of AI/ML-based CSI compression using two-sided model in Release 19, adopt the following evaluation assumptions:

· CSI-RS configuration

o Periodic: 5 ms periodicity (baseline), 20 ms periodicity(encouraged)

o Aperiodic (for cases with prediction): Optional, CSI-RS burst with K resources and time interval m milliseconds (based on R18 MIMO eType-II)

· CSI reporting periodicity: {5, 10, 20} ms; other values are not precluded

· For cases with the use of past CSI information, to report observation window, including number/time distance of historic CSI/channel measurements.

· For cases with prediction, to report prediction window, including number/time distance of predicted CSI/channel.

R1-2401560 Summary#4 for Additional study on AI/ML for NR air interface: CSI compression Moderator (Qualcomm)

From Thursday session

Agreement

To alleviate / resolve the issues related to inter-vendor training collaboration of AI/ML-based CSI compression using two-sided model, study the following options:

Option 1: Fully standardized reference model (structure + parameters)
Option 2: Standardized dataset
Option 3: Standardized reference model structure + Parameter exchange between NW-side and UE-side
Option 4: Standardized data / dataset format + Dataset exchange between NW-side and UE-side
Option 5: Standardized model format + Reference model exchange between NW-side and UE-side

Note 1: The above options may not be mutually exclusive and may be used together.

Note 2: Other options are not precluded.

Note 3: The study should consider how different methods of exchanging the parameters / dataset / reference model would affect the feasibility and collaboration complexity of options 3 / 4 / 5 respectively, e.g., over the air-interface, offline delivery, etc.

Note 4: “Dataset” refers to a set of data samples of CSI feedback and associated target CSI.

Agreement

For the evaluation of AI/ML-based CSI compression using localized models in Release 19, consider the following options as a starting point to model the spatial correlation in the dataset for a local region:

Option 1: The dataset is derived from UEs dropped within the local region, with spatial consistency modelling as per TR 38.901.

E.g., Dropped in a specific cell or within a specific boundary.

Option 2: By using a scenario/configuration specific to the local region.

E.g., Indoor-outdoor ratio, LOS-NLOS ratio, TXRU mapping, etc.

Agreement

For the evaluation of temporal domain aspects of AI/ML-based CSI compression using two-sided model in Release 19,

· adopt the CSI feedback overhead rate as reference, where the CSI feedback overhead rate is the average bit-rate of CSI feedback overhead across time.

Note: The CSI feedback overhead of a single report is calculated as in R18 CSI compression study.

Agreement

For the evaluation of temporal domain aspects of AI/ML-based CSI compression using two-sided model in Release 19, for cases with prediction of future CSI, in which prediction and compression are separated, to optionally evaluate a scheme with ideal prediction as an additional evaluation case for reference.

Note: The ideal prediction scheme should model realistic channel estimation.

Agreement

For the evaluation of temporal domain aspects of AI/ML-based CSI compression using two-sided model in Release 19, for Case 2, Case 4 and Case 5, study the performance impact resulting from non-ideal UCI feedback.

Agreement

For the study of inter-vendor collaboration issues for AI/ML-based CSI compression using a two-sided model, consider at least the following aspects when comparing different options:

· Inter-vendor collaboration complexity, e.g., whether bilateral collaboration is required between vendors.

· Performance.

· Interoperability and RAN4 / testing related aspects.

· Feasibility.

Final summary in R1-2401561.

9.1.3.33 Other aspects of AI/ML model and data

Including model identification/procedure, collection of UE-sided model training data, and model transfer/delivery

R1-2400048 Discussion on other aspects of AI/ML model and data Spreadtrum Communications

R1-2400094 Discussion on other aspects of AI/ML model and data on AI/ML for NR air-interface FUTUREWEI

R1-2400147 Discussion on other aspects of the additional study for AI/ML Huawei, HiSilicon

R1-2400172 Discussion on other aspects of AI/ML Ericsson

R1-2400236 Other aspects of AI/ML model and data vivo

R1-2400266 Discussion on study for other aspects of AI/ML model and data ZTE

R1-2400320 Discussion on other aspects of AI/ML model and data CMCC

R1-2400380 Other study aspects of AI/ML for air interface Intel Corporation

R1-2400396 AI/ML Model and Data Google

R1-2400422 Study on other aspects of AI/ML model and data CATT

R1-2400466 Discussion on other aspects of AI/ML model and data NEC

R1-2400514 On AI model transfer Dell Technologies

R1-2400547 Further study on AI/ML model and data xiaomi

R1-2400622 Additional study on other aspects of AI/ML model and data OPPO

R1-2400696 Additional study on other aspects of AI model and data NVIDIA

R1-2400724 Discussion for further study on other aspects of AI/ML model and data Samsung

R1-2400758 On other aspects of AI/ML model and data CICTCI

R1-2400770 Discussion on other aspects of AI/ML model and data Fujitsu

R1-2400780 Discussion on other aspects of AI/ML model and data Continental Automotive

R1-2400797 Other Aspects of AI/ML Model and Data Nokia, Nokia Shanghai Bell

R1-2400834 On aspects of AI/ML model and data framework Lenovo

R1-2400910 Discussion on other aspects of AI/ML model and data InterDigital, Inc.

R1-2401006 Discussion on other aspects of AI/ML model and data Apple

R1-2401038 Discussion on other aspects for AI/ML for air interface Panasonic

R1-2401479 Discussion on functionality update, model identification, data collection and model transfer NTPU (rev of R1-2401060)

R1-2401111 Discussion on other aspects of AI/ML model and data NTT DOCOMO, INC.

R1-2401138 View on AI/ML model and data MediaTek Korea Inc.

R1-2401175 Discussions on other aspects of AI/ML model and data Sharp

R1-2401225 Discussion on other aspects of AI/ML model and data ETRI

R1-2401366 Other Aspects of AI/ML framework AT&T

R1-2401435 Other aspects of AI/ML model and data Qualcomm Incorporated

R1-2401569 Summary #1 for other aspects of AI/ML model and data Moderator (OPPO)

Presented in Monday session.

R1-2401570 Summary #2 for other aspects of AI/ML model and data Moderator (OPPO)

From Tuesday session

This agreement cited from RAN1#115 for reference only

Agreement

For model identification of UE-side or UE-part of two-sided models, further clarification is made as follows.

· The following are example use cases Type B1 and B2

o Model identification in model transfer from NW to UE

o Model identification with data collection related configuration(s) and/or indication(s) and/or dataset transfer

· Note: Other example use cases are not precluded.

· Note: Offline model identification may be applicable for some of the above example use cases

R1-2401571 Summary #3 for other aspects of AI/ML model and data Moderator (OPPO)

From Wednesday session

Agreement

· To facilitate the discussion, RAN1 studies the model identification type A with more details related to use cases.

· To facilitate the discussion, RAN1 studies the following options as starting point for model identification type B with more details related to all use cases.

o MI-Option 1: Model identification with data collection related configuration(s) and/or indication(s)

o MI-Option 2: Model identification with dataset transfer

o MI-Option 3: Model identification in model transfer from NW to UE

o FFS: The boundary of the options

o Note: the names (MI-Opton1, MI-Option 2, MI-Option 3) are used only for discussion purpose

o Note: other options are not precluded

Observation

The other options are proposed for model identification type B by companies during the discussion:

· MI-Option 4. Model identification via standardization of reference models. (for CSI compression)

· MI-Option 5. Model identification via model monitoring

R1-2401572 Summary #4 for other aspects of AI/ML model and data Moderator (OPPO)

From Thursday session

Agreement

Regarding MI-Option 1 (Model identification with data collection related configuration(s) and/or indication(s)) of model identification type B, RAN1 further study the following aspects:

Relationship between model ID and data collection related configuration(s) and/or indication(s)
Information transmitted from NW to UE (if any)
Information transmitted from UE to NW (if any)
The associated procedure
Usage/Applicable use case(s) of MI-Option 1

Note: whether MI-Option 1 is needed or not is a separate discussion.

Conclusion

From RAN1 perspective, the model transfer/delivery Case z5 is deprioritized for Rel-19.

Conclusion

RAN1 has no consensus to reply the SA5 LS (R1-2400035).

Final summary in R1-2401573.

RAN1#116-bis

9.1 Artificial Intelligence (AI)/Machine Learning (ML) for NR Air Interface

Please refer to RP-240774 for detailed scope of the WI.

R1-2403662 Session notes for 9.1 (AI/ML for NR Air Interface) Ad-Hoc Chair (CMCC)

Friday decision: The session notes are endorsed and contents reflected below.

[116bis-R19-AI/ML] – Taesang (Qualcomm)

Email discussion on Rel-19 AI/ML

- To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc

9.1.1 Specification support for beam management

R1-2402023 Discussion on AI/ML for beam management Huawei, HiSilicon

R1-2402054 Discussion on specification support for AI/ML-based beam management FUTUREWEI

R1-2402056 AI/ML for beam management Ericsson

R1-2402094 Discussion on AIML for beam management Spreadtrum Communications

R1-2402144 Specification support for AI/ML for beam management Intel Corporation

R1-2402230 Specification support for beam management vivo

R1-2402263 Discussion on specification support for AI/ML beam management ZTE

R1-2402276 AI/ML based Beam Management Google

R1-2402316 On specification for AI/ML-based beam management OPPO

R1-2402366 Specification support for AI/ML-based beam management CATT

R1-2402491 Discussion for supporting AI/ML based beam management Samsung

R1-2402553 Discussion on specification support for beam management CMCC

R1-2402609 Discussion on AI/ML for beam management InterDigital, Inc.

R1-2402626 Discussion on specification support for beam management Panasonic

R1-2402628 Discussions on AI/ML for beam management LG Electronics

R1-2402649 Specification support for beam management Xiaomi

R1-2402730 Discussions on AIML for beam management New H3C Technologies Co., Ltd.

R1-2402756 Discussion on specification support for beam management NEC

R1-2402786 Discussion on specification support on AI/ML for beam management Fujitsu

R1-2402846 Specification support for AI-enabled beam management NVIDIA

R1-2402869 On AI/ML for beam management Apple

R1-2402918 AI/ML specification support for beam management Lenovo

R1-2402939 Discussion on specification support for AI/ML-based beam management MediaTek

R1-2402957 Discussions on AI/ML for beam management Sony

R1-2402996 AI/ML for Beam Management Nokia

R1-2403006 Specification support for AI/ML beam management ITL

R1-2403011 Discussion on specification support for beam management ETRI

R1-2403036 Discussion on AI/ML beam management TCL

R1-2403041 Specification support for beam management Fraunhofer HHI, Fraunhofer IIS

R1-2403051 Discussion on Specification Support for Beam Management CEWiT

R1-2403131 Discussion on AI/ML based beam management KT Corp.

R1-2403141 Specification support for beam management KDDI Corporation

R1-2403157 Discussions on AI/ML for beam management CAICT

R1-2403182 Specification support for AI-ML-based beam management Qualcomm Incorporated

R1-2403232 Discussion on AI/ML for beam management NTT DOCOMO, INC.

R1-2403299 Discussions on specification support for beam management Sharp

R1-2403367 Discussions on Specification Support of AI/ML for Beam Management Indian Institute of Tech (M), IIT Kanpur

R1-2403563 FL summary #0 for AI/ML in beam management Moderator (Samsung)

R1-2403568 FL summary #1 for AI/ML in beam management Moderator (Samsung)

From Tuesday session

Agreement

For UE-side AI/ML model inference, for BM-Case2, support to report inference results of N(N>=1, FFS on N) future time instance(s) in one report

· wherein information of inference results of one time instance is as in one report for BM-Case 1.

o Note: overhead reduction is not precluded.

· FFS on details

Agreement

For network-sided AI/ML model for BM-Case1 and BM-Case2,

· support using existing CSI framework for configuration of Set A as the starting point

· support using existing CSI framework for configuration of Set B as the starting point

· Note: Purpose, such as above "For NW-sided model, for BM-Case1 and BM-Case2" and "Set A" and "Set B", will not be specified in RAN 1 specifications

Agreement

For report content of inference results for UE-sided model for BM-Case 1, for the RSRP of predicted Top K beam(s) in the report of inference results, when applicable, further study the following options:

· Option A: Predicted RSRP.

· Option B: Predicted RSRP, if the beam is not configured for corresponding measurement, and measured L1-RSRP if the beam is configured for corresponding measurement.

· Where the predicted RSRP is based on AI/ML output.

· Note: Support both Option A and Option B is not precluded.

Working Assumption

For report content of inference results for UE-sided model for BM-Case 2, the RSRP of predicted beam(s) in the report of inference results, is the predicted RSRP, where the predicted RSRP is based on AI/ML output.

R1-2403569 FL summary #2 for AI/ML in beam management Moderator (Samsung)

Presented in Wednesday session

R1-2403570 FL summary #3 for AI/ML in beam management Moderator (Samsung)

From Thursday session

Agreement

For UE-sided model at least for BM Case-1, CSI-ReportConfig is used for the configuration of inference results reporting

FFS on the details in the CSI-ReportConfig, at least considering:

Alt 1: one CSI-ResourceConfigId is configured for Set B

FFS: how UE can determine the information about set A

Alt 2: one CSI-ResourceConfigId is configured for both Set A and Set B

FFS: How to configure resource set(s) for Set A and Set B in CSI-ResourceConfig

Alt 3: two CSI-ResourceConfigId s are configured for Set A and Set B separately
Alt 4: one CSI-ResourceConfigId is configured for Set B, Set A is configured using separate resource set(s) other than that represented by CSI-ResourceConfigId

FFS: how to configure/indicate separate resource set(s) for Set A

Note: separate CSI-ReportConfig for Set A and Set B are not precluded.
Note: Not perform measurement for Set A and only perform measurement for Set B subject to the CSI-ReportConfig

FFS on the association between Set A and Set B with or without additional IE
Other necessary configuration are not precluded.

R1-2403755 FL summary #4 for AI/ML in beam management Moderator (Samsung)

From Friday session

Agreement

Further study, for the consistency of NW-side additional condition across training and inference for UE-sided model for BM-Case 1 and BM Case 2, where the NW-side additional condition may at least impact UE assumption on beams of Set A/Set B:

Opt1: Based on associated ID (Referring to AI 9.1.3.3)

FFS on what can be assumed by UE with the same associated ID across training and inference
FFS on how associated ID is introduced, e.g., within CSI framework, or outside of CSI framework

Opt 2: Performance monitoring based

FFS details

Other options are not precluded.

Final summary in R1-2403756.

9.1.2 Specification support for positioning accuracy enhancement

R1-2401984 AI/ML for Positioning Accuracy Enhancement Ericsson Inc.

R1-2402024 Discussion on AI/ML for positioning accuracy enhancement Huawei, HiSilicon

R1-2402039 AI/ML positioning accuracy enhancement Fraunhofer IIS, Fraunhofer HHI

R1-2402145 Specification support for AI/ML for positioning accuracy enhancement Intel Corporation

R1-2402231 Specification support for positioning accuracy enhancement vivo

R1-2402264 Discussion on specification support for AI/ML positioning accuracy enhancement ZTE, Pengcheng laboratory

R1-2402277 AI/ML based Positioning Google

R1-2402317 On specification for AI/ML-based positioning accuracy enhancements OPPO

R1-2402367 Specification support for AI/ML-based positioning accuracy enhancement CATT, CICTCI

R1-2402492 Discussion for supporting AI/ML based positioning accuracy enhancement Samsung

R1-2402554 Discussion on specification support for positioning accuracy enhancement CMCC

R1-2402650 Discussion on AI/ML-based positioning accuracy enhancement Xiaomi

R1-2402764 Discussion on specification support for AI/ML based positioning accuracy enhancement NEC

R1-2402787 Discussion on specification support for AI/ML positioning accuracy enhancement Fujitsu

R1-2402799 Design for AI/ML based positioning MediaTek Korea Inc.

R1-2402847 Specification support for AI-enabled positioning NVIDIA

R1-2402870 On AI/ML for Positioning Accuracy Enhancement Apple

R1-2402913 Discussion on support for AIML positioning InterDigital, Inc.

R1-2402919 Specification impacts for Enhanced Positioning Lenovo

R1-2402958 Discussion on supporting AI/ML for positioning Sony

R1-2402997 AI/ML for Positioning Accuracy Enhancement Nokia

R1-2403012 Discussion on specification support for positioning accuracy enhancement ETRI

R1-2403035 Discussion on specification support for positioning accuracy enhancement TCL

R1-2403052 Discussion on specification support for AI/ML Positioning Accuracy enhancement CEWiT

R1-2403183 Specification support for AI-ML-based positioning accuracy enhancement Qualcomm Incorporated

R1-2403233 Discussion on AI/ML for positioning accuracy enhancement NTT DOCOMO, INC.

R1-2403300 Discussions on specification support for AI/ML based positioning accuracy enhancements Sharp

R1-2403458 Summary #1 of specification support for positioning accuracy enhancement Moderator (Ericsson)

From Monday session

Agreement

For AI/ML based positioning Case 3b, for gNB channel measurements reported to LMF, the timing information is represented relative to the existing UL RTOA reference time T₀+t_SRS as defined in TS 38.215.

FFS: whether it is applicable when Case 3b is used to support multi-RTT.

R1-2403459 Summary #2 of specification support for positioning accuracy enhancement Moderator (Ericsson)

R1-2403460 Summary #3 of specification support for positioning accuracy enhancement Moderator (Ericsson)

From Tuesday session

Conclusion

It is out of RAN1 scope to decide whether/how synthetic data (i.e., not direct physical data) and related entities are used in AI/ML based positioning. In RAN1 discussion, data (e.g., measurement data, label data) refer to physical data, not synthetic data.

Working Assumption

For training data generation of AI/ML based positioning Case 1, the measurement and its related data (e.g., timestamp) are generated by PRU and/or Non-PRU UE.

Agreement

For training data generation of AI/ML based positioning Case 3a and 3b, the measurement and its related data (e.g., timestamp) are generated by TRP/gNB.

Agreement

For training data collection of AI/ML based positioning, the collected data sample can include the following components:

Part A:

channel measurement
quality indicator of channel measurement
time stamp of channel measurement

Part B:

ground truth label (or its approximation)
quality indicator of label
time stamp of label

Note: "Part A" and "Part B" terminologies are only for RAN1 discussion purpose, and may not be used in specification.

Note: contents in Part A and Part B may or may not be generated by different entities.

Note: Part A and/or Part B, and their contents may or may not apply for each case

FFS: detailed definition of channel measurement

R1-2403461 Summary #4 of specification support for positioning accuracy enhancement Moderator (Ericsson)

R1-2403462 Summary #5 of specification support for positioning accuracy enhancement Moderator (Ericsson)

From Thursday session

Working Assumption

For training data generation of AI/ML based positioning Case 2a and 2b, the channel measurement and its related data (e.g., time stamp) are generated by PRU and/or non-PRU UE.

Working Assumption

For training data generation of AI/ML based positioning Case 1, the label and its related data (e.g., time stamp) can be generated by:

PRU
Non-PRU UE with estimated location
LMF

Note: transfer of the label and its related data is out of RAN1 scope.

Working Assumption

For training data generation of AI/ML based positioning Case 2a, the label and its related data (e.g., time stamp) can be generated by:

PRU
Non-PRU UE with estimated location
LMF

Note: transfer of the label and its related data is out of RAN1 scope.

Working Assumption

For training data generation of AI/ML based positioning Case 2b, the label and its related data (e.g., time stamp) can be generated by:

PRU
Non-PRU UE with estimated location
LMF

Note: transfer of label and its related data is out of RAN1 scope.

Working Assumption

For training data generation of AI/ML based positioning Case 3b, the label and its related data (e.g., time stamp) can be generated by:

PRU
FFS: Non-PRU UE with estimated location
LMF

Note: transfer of label and its related data is out of RAN1 scope.

Agreement

For training data generation of AI/ML based positioning Case 3a, the label and its related data (e.g., time stamp) can be generated by at least:

Note: transfer of label and its related data is out of RAN1 scope.

Note: whether other network entities can generate label for Case 3a is out of RAN1 scope.

R1-2403740 Summary #6 of specification support for positioning accuracy enhancement Moderator (Ericsson)

From Friday session

Agreement

For AI/ML positioning Case 3a, for model performance monitoring metric calculation in label-based model monitoring, study the feasibility of the following options. To provide information on how to generate information on ground truth label for each option.

· Option A. NG-RAN node performs monitoring metric calculation for its own model.

· Option B. LMF performs monitoring metric calculation for the model located at the NG-RAN node.

Note: Final selection of Option A and Option B is out of RAN1 scope, but RAN1 can make recommendation about the option(s), and potential support of Option A and/or Option B is pending RAN3 confirmation.

Note: Exact method to perform the monitoring metric calculation is up to implementation

Agreement

For model performance monitoring of AI/ML positioning Case 1, for model performance monitoring metric calculation in label-based model monitoring, study the feasibility, benefits, and potential specification impact of the following options with regard to how to generate information on ground truth label:

Option A. The target UE side performs monitoring metric calculation.

Option A-1. At least information on ground truth label of the target UE is generated by LMF and provided to the target UE.

• In one example, target UE and/or gNB sends measurement (e.g., legacy measurement) to LMF so that LMF can derive the information on ground truth label.

Option A-2. At least position calculation assistance data (e.g., existing information for UE-based positioning method) is provided from LMF to the target UE.
Option A-3. Reuse Rel-18 assistance data transfer framework from LMF to the target UE, where the PRU measurement (e.g., legacy measurement) and the corresponding PRU location are sent via LMF to the target UE.
Option A-4. PRU measurement (and the corresponding PRU location if not already known at the UE-side) are sent from PRU to the target UE side ~~(e.g., target UE, OTT server)~~.

• Note: Option A-4 can be realized by implementation in a manner transparent to specification if the PRU sends information to the target UE side in a proprietary method.

Option B. The LMF performs monitoring metric calculation.

Option B-1. at least inference result (i.e., the model output corresponding to target UE’s channel measurement) of the target UE is sent by the target UE to LMF.
Option B-2. PRU’s channel measurement is sent via LMF to the target UE, and the inference result (i.e., the model output corresponding to PRU’s channel measurement) is sent by the target UE to LMF.

Note: exact method to perform the monitoring metric calculation is up to implementation.

Note: Other options are not precluded.

Final summary in R1-2403741.

9.1.3 Additional study on AI/ML for NR air interface

9.1.3.1 CSI prediction

R1-2402025 Discussion on AI/ML for CSI prediction Huawei, HiSilicon

R1-2402095 Discussion on AIML for CSI prediction Spreadtrum Communications

R1-2402146 AI/ML for CSI prediction Intel Corporation

R1-2402232 Discussion on CSI prediction vivo

R1-2402265 Discussion on study for AI/ML CSI prediction ZTE

R1-2402278 AI/ML based CSI Prediction Google

R1-2402318 Additional study on AI/ML-based CSI prediction OPPO

R1-2402368 Additional study on AI/ML-based CSI prediction CATT

R1-2402454 Discussion for further study on AI/ML-based CSI prediction Samsung

R1-2402494 AI/ML for CSI prediction Ericsson

R1-2402505 Discussion on AI/ML-based CSI prediction China Telecom

R1-2402535 AI/ML for CSI prediction Mavenir

R1-2402555 Discussion on AI/ML for CSI prediction CMCC

R1-2402629 Study on CSI prediction LG Electronics

R1-2402651 Discussion on one side AI/ML model based CSI prediction Xiaomi

R1-2402749 Discussion on AI/ML for CSI prediction Panasonic

R1-2402765 Discussion on CSI prediction NEC

R1-2402788 Discussion on CSI prediction with AI/ML Fujitsu

R1-2402842 Discussion on AI/ML-based CSI prediction InterDigital, Inc.

R1-2402848 Additional study on AI-enabled CSI prediction NVIDIA

R1-2402871 Discussion on AI based CSI prediction Apple

R1-2402920 On AI/ML for CSI prediction Lenovo

R1-2402959 Discussions on cell/site-specific CSI prediction Sony

R1-2402998 AI/ML for CSI Prediction Nokia

R1-2403053 Discussion on AI/ML for CSI Prediction CEWiT

R1-2403075 Additional Study on AI/ML for CSI Prediction MediaTek

R1-2403096 Discussion on AI/ML for CSI prediction SK Telecom

R1-2403146 Discussion on AI/ML for CSI prediction AT&T

R1-2403184 Additional study on CSI prediction Qualcomm Incorporated

R1-2403234 Discussion on AI/ML for CSI prediction NTT DOCOMO, INC.

R1-2403379 Discussion on study of AI/ML for CSI prediction IIT Kanpur, Indian Institute of Tech (M)

R1-2403481 Summary #1 of CSI prediction Moderator (LG Electronics)

From Tuesday session

Agreement

· For the AI/ML based CSI prediction, adopt following assumptions as a baseline for evaluation purpose

o UE speed: 30km/h, 60km/h

§ Others can be additionally submitted, e.g., 10km/h, 120km/h

o Observation window (number/distance): 5/5ms,10/5ms

§ Others can be additionally submitted, e.g., 4/5ms, 15/5ms

o Prediction window (number/distance between prediction instances/distance from the last observation instance to the 1st prediction instance): 1/5ms/5ms, 4/5ms/5ms

§ Others can be additionally submitted, e.g., 2/5ms/5ms, 3/5ms/5ms, 1/5ms/10ms

o For other assumptions, reuse Rel-18 baseline

Agreement

· For the AI/ML based CSI prediction, for CSI report, adopt following as a baseline for evaluation purpose

o N4 value: 1, 4

§ Others can be additionally submitted, e.g., 2, 8

o paramCombination-Doppler-r18: 6,7 or paramCombination -r16 = 5,6 (for Benchmark 1)

§ Others can be additionally submitted.

§ Note: The same selected parameter combination shall be applied for benchmarks.

o CSI report periodicity: 5ms, 20ms (encouraged)

§ Others can be additionally submitted, e.g., 10ms

Conclusion

Consider error modelling in TR36.897 Table A.1-2 as a baseline if channel estimation error is modeled.

· Other modelling is not precluded, and companies should report how to model channel estimation error if other modelling is considered.

Conclusion

If phase discontinuity is modeled, it is modelled as a uniform distribution between within a time window of, where =40 degrees ~~and~~ =20ms can be a baseline.

· Other modelling is not precluded, and companies should report how to model phase discontinuity if other modelling is considered, and additional , if adopted.

R1-2403482 Summary #2 of CSI prediction Moderator (LG Electronics)

R1-2403483 Summary #3 of CSI prediction Moderator (LG Electronics)

From Thursday session

Conclusion

For the phase discontinuity modelling, it is clarified that

· A fixed phase for all CSI-RS observations within the time window, and another fixed phase for the next time window. The phases are according to uniform distribution.

Conclusion

· For evaluation of the UE-sided model based CSI prediction, UE distribution of (80% indoor, 20% outdoor) can be optionally simulated.

Note: Indoor speed is 3 km/h, outdoor speed is chosen from the following options: 30 km/h, 60 km/h. Assumption on O2I car penetration loss and spatial consistency follow the Rel-18 AI/ML based CSI prediction

Agreement

For the results template used to collect evaluation results for UE -sided model based CSI prediction, adopt Table 6 used in Rel-18 as starting point with the following addition:

Assumption

UE distribution (Baseline: 100% outdoor, Optional: 80% indoor, 20% outdoor)
Whether/how channel estimation error is modelled
Whether/how phase discontinuity is modelled
Methods used to handle the phase discontinuity (if applied)

Benchmark 2

FLOPs/M
Details of complexity calculation, e.g., complexity of prediction and complexity of filter update

Agreement

For the results template used to collect evaluation results for UE-sided model based CSI prediction using localized models, adopt Table 6 used in Rel-18 as starting point, capturing the generalized model result and the localized model result as separate columns, with the following additions for the localized model:

· Dataset description

o Local region modelling: e.g., Option 1 or Option 2, and further details

o Temporal modelling: e.g., how temporal variation is modelled in train and test sets

o Dataset description for generalized model

Agreement

For the UE-sided model based CSI prediction, for optional evaluation using AP CSI-RS, consider following assumption on observation window (number/distance)

· Observation window: 12/2ms, 8/2ms, 4/2ms

· Others can be additionally submitted

Agreement

For AI/ML based CSI prediction, at least for inference, legacy CSI-RS configuration can be a starting point. Further study on whether there is a need for specification enhancement.

Agreement

At least for inference, for UE-sided model based CSI prediction, legacy feedback mechanism using codebook type set to “typeII-Doppler-r18” is a starting point of discussion. Study the necessity and potential specification impacts including at least following aspects:

· CSI processing criteria and timeline

Agreement

For performance monitoring for functionality-based LCM, further study on details of type 1,2 and 3, e.g., potential specification impact, pros/cons aspects.

o To clarify the boundary between type 1 and type 3

o To clarify definition of monitoring output and performance metric

Final summary in R1-2403484.

9.1.3.2 CSI compression

R1-2402026 Discussion on AI/ML for CSI compression Huawei, HiSilicon

R1-2402053 Discussion on improving trade-off between performance and complexity/overhead for AI/ML-based temporal-domain CSI feedback compression. FUTUREWEI

R1-2402096 Discussion on AIML for CSI compression Spreadtrum Communications

R1-2402147 AI/ML for CSI compression Intel Corporation

R1-2402233 Discussion on CSI compression vivo

R1-2402266 Discussion on study for AI/ML CSI compression ZTE

R1-2402279 AI/ML based CSI Compression Google

R1-2402319 Additional study on AI/ML-based CSI compression OPPO

R1-2402369 Additional study on AI/ML-based CSI compression CATT

R1-2402455 Discussion for further study on AI/ML-based CSI compression Samsung

R1-2402495 AI/ML for CSI compression Ericsson

R1-2402506 Discussion on AI/ML-based CSI compression China Telecom

R1-2402526 Discussion on CSI compression for AI/ML BJTU

R1-2402556 Discussion on AI/ML for CSI compression CMCC

R1-2402630 Study on CSI compression LG Electronics

R1-2402652 Discussion on two-sided AI/ML model based CSI compression Xiaomi

R1-2402750 Discussion on AI/ML for CSI compression Panasonic

R1-2402766 Discussion on CSI compression NEC

R1-2402789 Discussion on CSI compression with AI/ML Fujitsu

R1-2402843 Discussion on AI/ML-based CSI compression InterDigital, Inc.

R1-2402849 Additional study on AI-enabled CSI compression NVIDIA

R1-2402872 Discussion on AI based CSI compression Apple

R1-2402921 On AI/ML for CSI compression Lenovo

R1-2402960 Discussion on CSI compression Sony

R1-2402999 AI/ML for CSI Compression Nokia

R1-2403013 Discussion on AI/ML for CSI compression ETRI

R1-2403054 Discussion on AI/ML for CSI Compression CEWiT

R1-2403076 Additional Study on AI/ML for CSI Compression MediaTek

R1-2403100 Discussion on AI/ML for CSI compression SK Telecom

R1-2403147 Discussion on AI/ML for CSI compression AT&T

R1-2403158 Discussions on AI/ML for CSI feedback CAICT

R1-2403185 Additional study on CSI compression Qualcomm Incorporated

R1-2403235 Discussion on AI/ML for CSI compression NTT DOCOMO, INC.

R1-2403279 AI/ML based CSI compression ITL

R1-2403336 Discussion on the AI/ML for CSI Compression Fraunhofer IIS, Fraunhofer HHI

R1-2403380 Discussion on study of AI/ML for CSI compression IIT Kanpur, Indian Institute of Tech (M)

R1-2403381 Discussion on Additional Study of AI/ML for CSI Compression Indian Institute of Tech (M), IIT Kanpur

R1-2403500 Summary#1 of Additional study on AI/ML for NR air interface: CSI compression Moderator (Qualcomm)

From Monday session

Agreement

For the results template used to collect evaluation results for temporal domain compression Case 1/2/5, adopt Table 1 used in Rel-18 as starting point with the following additions:

Temporal domain CSI setting

CSI feedback periodicity
CSI-RS periodicity

Description of model input/output and Case

Compression case, e.g., Case 1/2/5
Usage of historical CSI at UE/NW side (e.g., number / time distance, eigen-vectors / raw channels, etc)
Methods to handle UCI loss (if applicable), e.g., CSI buffer reset, CSI retransmission, etc.
Methods to handle rank adaptation (if applicable)

UE distribution (Option 1 or Option 2) and UE speed
CSI feedback overhead rate: X/Y/Z bits per normalized time unit

Normalized time unit = 5ms and adopt same X/Y/Z values as in Table 1 of Rel-18

Benchmark scheme

Rel-16 eT2 and compression Case 0 (i.e., Rel-18 AI/ML based CSI compression)

Whether/how spatial consistency is modelled
Whether/how UCI loss is modelled

The same UCI loss model shall be applied to the benchmark for fair comparison.

Whether/how rank adaptation is modelled
Modelling of channel estimation error
Whether/how phase discontinuity is modelled (if applicable)

Agreement

For the results template used to collect evaluation results for temporal domain prediction and compression Case 3/4, adopt Table 1 used in Rel-18 as starting point with the following additions:

Temporal domain CSI setting

CSI feedback periodicity
CSI-RS periodicity

Description of model input/output and use case

Compression case, e.g., case 3 / 4
Observation window (usage of historical CSI at UE/NW side, e.g., number / time distance, eigen-vectors / raw channels, etc)
Prediction window (e.g., time distance between 1^st prediction instance and last observation instance, number / time distance of predicted CSI)
Methods to handle UCI loss (if applicable)

UE distribution (Option 1 or Option 2) and UE speed
CSI feedback overhead rate: X/Y/Z bits per normalized time unit

Normalized time unit = 5ms and adopt same X/Y/Z values as in Table 1 of Rel-18

SGCS values before (if applicable) and after compression
Assumption on the prediction of future CSI

Separate step or jointly with compression
If separate, description of the AI or non-AI prediction algorithms: ideal prediction, AI-based prediction, non-AI-based prediction (e.g., nearest historical CSI and its location, learning window size / time correlation matrix size for auto-regression based prediction),

Note: the same prediction algorithm to be used for the benchmark scheme.

Benchmark schemes

Description of feedback schemes, i.e., Rel-18 doppler eT2

Whether/how spatial consistency is modelled
Whether/how UCI loss is modelled

The same UCI loss model shall be applied to the benchmark for fair comparison.

Modelling of channel estimation error
Whether/how phase discontinuity is modelled (if applicable) ~~Modelling of phase discontinuity~~

Conclusion (from Friday session)

For multi-vendor results table, adopt Rel-18 Table 4 for joint training and Rel-18 Table 5 for separate training as starting point, with the same additions of above 2 agreements.

R1-2403501 Summary#2 of Additional study on AI/ML for NR air interface: CSI compression Moderator (Qualcomm)

From Tuesday session

Agreement

For Option 3, further define the two sub-options:

3a: Parameters received at the UE or UE-side goes through offline engineering at the UE-side (e.g., UE-side OTT server), e.g., potential re-training, re-development of a different model, and/or offline testing.
3b: Parameters received at the UE are directly used for inference at the UE without offline engineering, potentially with on-device operations.

For Option 5, further define the two sub-options:

5a: Model received at the UE or UE-side goes through offline engineering at the UE-side (e.g., UE-side OTT server), e.g., potential re-training, re-development of a different model, and/or offline testing.
5b: Model received at the UE are directly used for inference at the UE without offline engineering, potentially with on-device operations.

For Option 4, it is clarified that:

Dataset received at the UE or UE-side goes through offline engineering at the UE- side (e.g., UE-side OTT server), e.g., model training or offline testing.

Note: The descriptions under each option are only for the purpose of simplified discussion and do not mean deprioritizing any other flavours (such as an exchange originating from the UE-side and ending at the NW-side) from potential specification.

Agreement (amended as shown in red in Wednesday session)

For Option 3/4/5, focus further discussion on the following assumptions:

Option 3a/5a

The model(5a)/parameter(3a) exchange originates from the NW-side and ends at the UE-side.
Model(5a)/parameters(3a) exchanged from the NW-side to UE-side is either CSI generation or reconstruction part or both.

Option 3a-1/5a-1: Model/Parameters exchanged from the NW-side to UE-side is CSI generation part.
Option 3a-2/5a-2: Model/Parameters exchanged from the NW-side to UE-side is CSI reconstruction part.
Option 3a-3/5a-3: Model/Parameters exchanged from the NW-side to UE-side are both CSI generation part and CSI reconstruction part.
Some additional information, if necessary, may be shared from the NW-side to help UE-side offline engineering and provide performance guidance.

Performance target
Dataset or information related to collecting dataset

Study different methods of exchanging, e.g., over the air-interface, offline delivery, etc.

Option 3b

The method of exchanging is over the air-interface via model transfer/delivery Case z4.
The parameter exchange is from NW to UE.
Parameters exchanged from the NW-side to UE-side is CSI generation part.

Option 5b

The method of exchanging is over the air-interface via model transfer/delivery Case z4, assuming that the model structure is aligned based on offline inter-vendor collaboration.
The model exchange is from NW to UE.
Model exchanged from the NW-side to UE-side is CSI generation part.

Option 4:

The dataset exchange originates from the NW-side and ends at the UE-side.
Option 4-1: Dataset exchanged from the NW-side to UE-side consists of (target CSI, CSI feedback).
Option 4-2: Dataset exchanged from the NW-side to UE-side consists of (CSI feedback, reconstructed target CSI).
Option 4-3: Dataset exchanged from the NW-side to UE-side consists of (target CSI, CSI feedback, reconstructed target CSI).
Some additional information, if necessary, may be shared from the NW-side to help UE-side offline engineering and provide performance guidance.

Performance target

Study different methods of exchanging, e.g., over the air-interface, offline delivery, etc.

Note: For each option/sub-option of interest, companies to bring discussion on how inter-vendor collaboration complexity, interoperability, and feasibility may be addressed. Companies to strive to provide solution(s) that can address all the following aspects: inter-vendor collaboration complexity, performance, interoperability, and feasibility.
Note: The descriptions under each option are only for the purpose of simplified discussion and do not mean deprioritizing any other flavours (such as an exchange originating from the UE-side and ending at the NW-side) from potential specification.

R1-2403502 Summary#3 of Additional study on AI/ML for NR air interface: CSI compression Moderator (Qualcomm)

From Wednesday session

Agreement

For the results template used to collect evaluation results for AI/ML-based CSI compression using localized models, adopt Table 1 used in Rel-18 as starting point, capturing the generalized model result and the localized model result as separate columns, with the following additions for the localized model:

· Dataset description

o Local region modelling: e.g., Option 1 or Option 2, and further details

o Temporal modelling: e.g., how temporal variation is modelled in train and test sets

o Dataset description for generalized model

R1-2403503 Summary#4 of Additional study on AI/ML for NR air interface: CSI compression Moderator (Qualcomm)

From Thursday session

Conclusion

In Rel-19 study of temporal domain aspects of AI/ML-based CSI compression using two-sided model, CSI prediction that is performed entirely at NW-side is deprioritized.

Agreement

For the evaluation of temporal domain aspects of AI/ML-based CSI compression using two-sided model in Release 19, for the temporal domain prediction and compression Case 3 and Case 4, adopt the following evaluation assumptions as baseline:

· Observation window (number/distance):

o For periodic CSI-RS with 5ms periodicity: 12/5ms, 10/5ms, 8/5ms, 5/5ms, 4/5ms, unrestricted observation window

o For periodic CSI-RS with 20ms periodicity: up to companies (encouraged)

o For aperiodic CSI-RS: 12/2ms, 8/2ms, 4/2ms

o Others can be additionally submitted

· Prediction window (number/distance between prediction instances/distance from the last observation instance to the 1st prediction instance): 4/5ms/5ms

o Others can be additionally submitted, e.g. 4/1ms/5ms, 8/1ms/5ms, 4/5ms/10ms, 1/-/5ms

R1-2403504 Summary#5 of Additional study on AI/ML for NR air interface: CSI compression Moderator (Qualcomm)

From Friday session

Conclusion

For model generalization results table, adopt Rel-18 Table 2 and Generalization Case 1 / 2 / 3 as starting point with same additions above. For generalization aspects, adopt the following

· Various UE speed

· UE distribution

· Various CSI-RS periodicity

Conclusion

For model scalability results table, adopt Rel-18 Table 3 and Generalization Case 1 / 2 / 3 as starting point with same additions above. For generalization aspects, adopt the following

· Various numbers of antenna ports

· Various frequency granularity

· Various payload size

Conclusion:

· Conclude, from RAN1 perspective, that Option 1, if feasible for specification, eliminate the inter-vendor collaboration complexity (e.g., whether bilateral collaboration is required between vendors).

· It is RAN1’s understanding that Option 1 corresponds to RAN4 options, e.g., RAN4-Option3, or RAN4-Option4. Further study and final conclusion on interoperability and RAN4 testing of the RAN4-Option3 and RAN4-Option4 is up to RAN4.

Observation

· Option 1 and 2 may have limited performance in the field compared to Options 3, 4, and 5, further study is needed

· Option 1 and 2 may require high specification effort from RAN1 perspective.

Conclusion

Deprioritize Option 2 for inter-vendor training collaboration.

Note: This de-prioritization shall not affect the ongoing discussion in RAN4 on RAN4-Option3 and RAN4-Option4.

Agreement

For the results template used to collect evaluation results for temporal domain prediction and compression Case 4, adopt Table 1 used in Rel-18 as starting point with the following additions:

Description of model input/output and use case

Methods to handle rank adaptation (if applicable)

Final summary in R1-2403505.

9.1.3.33 Other aspects of AI/ML model and data

Including model identification/procedure, collection of UE-sided model training data, and model transfer/delivery

R1-2402027 Discussion on other aspects of the additional study for AI/ML Huawei, HiSilicon

R1-2402052 Discussion on other aspects of AI/ML model and data on AI/ML for NR air-interface FUTUREWEI

R1-2402057 Discussion on other aspects of AI/ML Ericsson

R1-2402097 Discussion on other aspects of AI/ML model and data Spreadtrum Communications

R1-2402148 Other study aspects of AI/ML for air interface Intel Corporation

R1-2402234 Other aspects of AI/ML model and data vivo

R1-2402267 Discussion on study for other aspects of AI/ML model and data ZTE

R1-2402280 AI/ML Model and Data Google

R1-2402320 Additional study on other aspects of AI/ML model and data OPPO

R1-2402370 Additional study on other aspects of AI/ML model and data CATT, CICTCI

R1-2402456 Discussion for further study on other aspects of AI/ML model and data Samsung

R1-2402557 Discussion on other aspects of AI/ML model and data CMCC

R1-2402631 Discussion on other aspects of AI/ML model and data LG Electronics

R1-2402653 Further study on AI/ML model and data Xiaomi

R1-2402695 Discussion on other aspects for AI/ML for air interface Panasonic

R1-2402757 Discussion on other aspects of AI/ML model and data NEC

R1-2402790 Discussion on other aspects of AI/ML model and data Fujitsu

R1-2402800 View on AI/ML model and data MediaTek Korea Inc.

R1-2402801 Discussion on other aspects of AI/ML model and data Continental Automotive

R1-2402844 Discussion on other aspects of AI/ML model and data InterDigital, Inc.

R1-2402850 Additional study on other aspects of AI model and data NVIDIA

R1-2402873 Discussion on other aspects of AI/ML model and data Apple

R1-2402922 On aspects of AI/ML model and data framework Lenovo

R1-2403000 Other Aspects of AI/ML Model and Data Nokia

R1-2403014 Discussion on other aspects of AI/ML model and data ETRI

R1-2403148 Other Aspects of AI/ML framework AT&T

R1-2403186 Other aspects of AI/ML model and data Qualcomm Incorporated

R1-2403236 Discussion on other aspects of AI/ML model and data NTT DOCOMO, INC.

R1-2403489 Summary #1 for other aspects of AI/ML model and data Moderator (OPPO)

From Monday session

Conclusion

From RAN1 perspective, the model transfer/delivery Case z2 is deprioritized at least for UE-sided model in Rel-19 due to the following reasons:

· Risk of proprietary design disclosure

· Burden of offline cross-vendor collaboration

Conclusion

From RAN1 perspective, the model transfer/delivery Case z3 is deprioritized for Rel-19 due to the following reasons (compared to Case y):

· No much benefit compared to Case y

· Risk of proprietary design disclosure

· Large burden of offline cross-vendor collaboration

· Additional burden on model storage within in 3GPP network

R1-2403490 Summary #2 for other aspects of AI/ML model and data Moderator (OPPO)

From Thursday session

Conclusion

It is clarified that MI-Option 4 refers to the Option 1 of CSI compression

Option 1: Fully standardized reference model (structure + parameters)

Agreement

From RAN1 perspective, for UE-sided model(s) developed (e.g., trained, updated) at UE side, following procedure is an example (noted as AI-Example1) of MI-Option1 for further study (including the feasibility/necessity)

A: For data collection, NW signals the data collection related configuration(s) and it/their associated ID(s)

Associated IDs for each sub use case in relation with NW-sided additional conditions

B: UE(s) collects the data corresponding to the associated ID(s)
C: AI/ML models are developed (e.g., trained, updated) at UE side based on the collected data corresponding to the associated ID(s).
D: UE reports information of its AI/ML models corresponding to associated IDs to the NW. Model ID is determined/assigned for each AI/ML model

relationship between model ID(s) and the associated ID(s)
How model ID(s) is determined/assigned, e.g.,

Alt.1: NW assigns Model ID
Alt.2: UE assigns/reports Model ID
Alt.3: Associated ID(s) is assumed as model ID(s)

“Model ID is determined/assigned for each AI/ML model” in D is not needed

Alt.4: Model ID is determined by pre-defined rule(s) in the specification

FFS: how to report
Note: D is to facilitate AI/ML model inference

Note: Step A/B/C and additional interaction of associated IDs between UE and NW can be considered as a different solution for resolving the consistency without model identification.

Final summary in R1-2403493.

RAN1#117

9.1 Artificial Intelligence (AI)/Machine Learning (ML) for NR Air Interface

Please refer to RP-240774 for detailed scope of the WI.

R1-2405695 Session notes for 9.1 (AI/ML for NR Air Interface) Ad-Hoc Chair (CMCC)

Friday decision: The session notes are endorsed and contents reflected below.

[117-R19-AI/ML] – Taesang (Qualcomm)

Email discussion on Rel-19 AI/ML

- To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc

9.1.1 Specification support for beam management

R1-2403866 Discussion on specification support for beam management FUTUREWEI

R1-2403914 AIML for beam management Ericsson

R1-2403929 Discussion on AI/ML for beam management Huawei, HiSilicon

R1-2403973 Specification support for AI/ML for beam management Intel Corporation

R1-2403998 Discussions on AIML for beam management New H3C Technologies Co., Ltd.

R1-2403999 Discussion on AI/ML beam management TCL

R1-2404015 Discussion on AIML for beam management Spreadtrum Communications

R1-2404137 Discussion for supporting AI/ML based beam management Samsung

R1-2404165 Specification support for beam management vivo

R1-2404272 Discussion on AI/ML-based beam management Apple

R1-2404311 Discussion on AI/ML for beam management InterDigital, Inc.

R1-2404384 Discussion on AI/ML for beam management CATT

R1-2404421 Discussion on specification support for AI/ML beam management China Telecom

R1-2404444 Discussion on specification support for beam management CMCC

R1-2404490 Discussions on AI/ML for beam management Sony

R1-2404525 AI/ML specification support for beam management Lenovo

R1-2404536 Specification support for AI-enabled beam management NVIDIA

R1-2404546 Discussions on AI/ML for beam management LG Electronics

R1-2404567 Discussion on specification support for beam management Panasonic

R1-2404582 Discussion on specification support on AI/ML for beam management Fujitsu

R1-2404601 Specification support for beam management Xiaomi

R1-2404655 Discussion on specification support for beam management NEC

R1-2404682 AI/ML based Beam Management Google

R1-2404701 Discussion on specification support for AI/ML beam management ZTE

R1-2404721 Discussions on AI/ML for beam management CAICT

R1-2404737 Discussion on AI/ML based beam management Hyundai Motor Company

R1-2404766 Discussion on specification support for beam management ETRI

R1-2404802 Prediction of untransmitted beams in a UE-side AI-ML model Rakuten Mobile, Inc

R1-2404877 On specification for AI/ML-based beam management OPPO

R1-2404903 Specification support for beam management Fraunhofer HHI, Fraunhofer IIS

R1-2404904 AI/ML for Beam Management Nokia

R1-2405030 Discussion on AI/ML for beam management NTT DOCOMO, INC.

R1-2405068 Discussions on specification support for beam management Sharp

R1-2405087 Discussion on specification support for AI/ML-based beam management MediaTek Inc.

R1-2405096 Discussion on AI/ML based beam management KT Corp.

R1-2405121 Discussions on specification support for beam management Ruijie Networks Co. Ltd

R1-2405143 Specification support for AI-ML-based beam management Qualcomm Incorporated

R1-2405223 Specification support for AI/ML beam management ITL

R1-2405234 Discussion on Specification Support for Beam Management CEWiT

R1-2405284 Discussions on Specification Support of AI/ML for Beam Management Indian Institute of Tech (M), IIT Kanpur

R1-2405336 Specification support for beam management KDDI Corporation

R1-2405427 FL summary #0 for AI/ML in beam management Samsung (Moderator)

From Monday session

Agreement

For BM-Case1 and BM-Case2 with a UE-side AI/ML model:

Support Type 1 performance monitoring, including the following two options:

Option 1 (NW-side performance monitoring):

UE sends a report to NW (for the calculation of performance metric at NW)

Measurement results from resource set for monitoring, e.g., L1-RSRP and/or RS index is supported as the content of the report
FFS on other contents

The report is at least configured/triggered by NW
Note: this may or may not have additional spec impact

Option 2 (UE-assisted performance monitoring):

UE calculates performance metric(s)

FFS how to report and what to report

FFS whether to trigger the report based on event(s) for Option 1 and/or Option 2

FFS Type 2 performance monitoring

R1-2405428 FL summary #1 for AI/ML in beam management Moderator (Samsung)

From Tuesday session

Agreement

At least for NW sided model, for the quantization of a reported L1-RSRP value at least for the report in L1 signaling, support

· Support differential L1-RSRP reporting with legacy quantization step and range

o FFS: larger quantization step(s) than the already supported legacy quantization step for differential L1-RSRP and/or for absolute L1-RSRP

o FFS: Smaller range(s) for differential L1-RSRP than the already supported legacy range

Agreement

Following Working Assumption is confirmed.

Working Assumption

R1-2405429 FL summary #2 for AI/ML in beam management Moderator (Samsung)

Presented in Wednesday session

R1-2405430 FL summary #3 for AI/ML in beam management Moderator (Samsung)

Presented in Thursday session

R1-2405679 FL summary #4 for AI/ML in beam management Moderator (Samsung)

From Friday session

Agreement

For NW-sided model, for inference report, at least for BM-Case 1, the content in a beam report in L1 signaling, support

· L1-RSRPs and corresponding beam information of Top M beam(s) with largest M measured value(s) of L1-RSRP(s) of a measurement resource set, where M is configured by gNB

o If M = the size of the measurement resource set, the content is all L1-RSRPs and one beam index (i.e., CRI/SSBRI) for the largest measured value of L1-RSRP of a measurement resource set

· FFS: L1-RSRPs and corresponding beam information of up to M beams within X dB gap to the largest measured value of L1-RSRP, X and M are configured by gNB, and whether/how to report number of reported beams

· FFS on the maximum value of M (where M can be larger than 4) based on UE capability (M may or may not be different for different reporting contents)

· FFS on beam information

· Note: Purpose, such as above “For NW-sided model, for inference report, at least for BM-Case 1”, will not be specified in RAN 1 specifications

Final summary in R1-2405680.

9.1.2 Specification support for positioning accuracy enhancement

R1-2403898 AI/ML for Positioning Accuracy Enhancement Ericsson (Late submission)

R1-2403930 Discussion on AI/ML for positioning accuracy enhancement Huawei, HiSilicon

R1-2403974 Specification support for AI/ML for positioning accuracy enhancement Intel Corporation

R1-2404002 Discussion on specification support for positioning accuracy enhancement TCL

R1-2404138 Discussion for supporting AI/ML based positioning accuracy enhancement Samsung

R1-2404166 Specification support for positioning accuracy enhancement vivo

R1-2404273 Discussion on Specification Support for AI/ML-based positioning Apple

R1-2404316 AI/ML positioning accuracy enhancement Fraunhofer IIS, Fraunhofer HHI

R1-2405350 Discussion on specification support for positioning accuracy enhancement Lekha Wireless Solutions (rev of R1-2404347 (Late submission))

R1-2404385 Discussion on AI/ML for positioning accuracy enhancement CATT, CICTCI

R1-2404445 Discussion on specification support for positioning accuracy enhancement CMCC

R1-2404478 Specification support for positioning accuracy enhancement Quectel

R1-2404491 Discussion on Specification Support for AI/ML Positioning Sony

R1-2404526 Specification impacts for Enhanced Positioning Lenovo

R1-2404537 Specification support for AI-enabled positioning NVIDIA

R1-2404583 Discussion on specification support for AI/ML positioning accuracy enhancement Fujitsu

R1-2404602 Discussion on AI/ML-based positioning accuracy enhancement Xiaomi

R1-2404650 Discussion on support for AIML positioning InterDigital, Inc.

R1-2404659 Discussion on specification support for AI/ML based positioning accuracy enhancement NEC

R1-2404683 AI/ML based Positioning Google

R1-2404763 Design for AI/ML based positioning MediaTek Korea Inc.

R1-2404767 Discussion on specification support for positioning accuracy enhancement ETRI

R1-2404878 On specification for AI/ML-based positioning accuracy enhancements OPPO

R1-2404905 AI/ML for Positioning Accuracy Enhancement Nokia

R1-2405031 Discussion on AI/ML for positioning accuracy enhancement NTT DOCOMO, INC.

R1-2405069 Discussion on specification support for AI/ML based positioning accuracy enhancements Sharp

R1-2405120 Discussion on specification support for AI/ML positioning accuracy enhancement ZTE, Pengcheng laboratory

R1-2405144 Specification support for AI-ML-based positioning accuracy enhancement Qualcomm Incorporated

R1-2405235 Discussion on specification support for AI/ML Positioning Accuracy enhancement CEWiT

R1-2405277 Discussions on positioning accuracy enhancement for AI/ML ITL

R1-2405283 Discussion on Specification Support of AI/ML for Positioning Accuracy Enhancement Indian Institute of Tech (M), IIT Kanpur

R1-2405385 Summary #1 of specification support for positioning accuracy enhancement Moderator (Ericsson)

From Monday session

Working Assumption

For training data generation of AI/ML based positioning Case 3b, the label and its related data (e.g., time stamp) can be generated by:

PRU
Non-PRU UE with estimated location
LMF

Note: transfer of label and its related data is out of RAN1 scope.

Note: It is assumed that user data privacy of non-PRU UE is preserved.

Note: Previous related working assumption made in RAN1#116bis for training data generation of AI/ML based positioning Case 3b will not need to be confirmed.

R1-2405386 Summary #2 of specification support for positioning accuracy enhancement Moderator (Ericsson)

Presented in Tuesday session.

R1-2405387 Summary #3 of specification support for positioning accuracy enhancement Moderator (Ericsson)

From Wednesday session

Agreement

Sample-based measurement is defined as:

The measurement is composed of Nt' samples of the estimated channel response in time domain. The timing information for the Nt' samples are reported with a timing granularity T, where T=2^kxTc. k represents the timing reporting granularity factor. Tc is the basic time unit for NR.

The corresponding measurement (e.g., power if reported) corresponds to the measurement for the reported Nt' samples.

Nt' and k can be signalled

FFS: the value range of Nt'; the value range of integer k for the timing granularity T.

The timing information is defined relative to a reference time

Further discussion is expected on the determination of Nt' and k (including signaling) , and a rule to be introduced for selecting Nt' samples.

Note: It doesn’t imply the definition of Sample-based measurement will be captured into the spec.

Agreement

Path-based measurement refers to the measurement in the existing specifications (up to Rel-18) including measurement reporting, with potential enhancements on the number of reported paths (if needed).

R1-2405388 Summary #4 of specification support for positioning accuracy enhancement Moderator (Ericsson)

From Thursday session

Agreement

For training data collection of AI/ML based positioning, if a training data sample contains both Part A and Part B, RAN1 assumes that Part A and Part B in one training data sample are:

for a same UE (PRU or Non-PRU UE), and
for a same location associated with Part B.

Note: the association can be discussed.

~~Note: Part A and Part B may be generated by the same or different entities, depending on the cases.~~

From AI 5

R1-2403835 LS on data collection to enable ML model training and inference in 5GC for Direct AI/ML based positioning SA2, vivo

Decision: Response to SA2 is necessary.

R1-2405577 [Draft] Reply LS on data collection to enable ML model training and inference in 5GC for direct AI/ML based positioning Ericsson

Thursday decision: The draft LS R1-2405577 is endorsed in principle by adding the latest agreements made in this meeting and adding “agreements” to “Note: the working assumptions above are based on RAN1 understanding for RAN work item (NR_AIML_air).”

Final LS is approved in R1-2405578.

Final summary in R1-2405389.

9.1.3 Additional study on AI/ML for NR air interface

9.1.3.1 CSI prediction

R1-2403909 AI/ML for CSI prediction Ericsson

R1-2403931 Discussion on AI/ML for CSI prediction Huawei, HiSilicon

R1-2403975 AI/ML for CSI prediction Intel Corporation

R1-2404016 Discussion on AIML for CSI prediction Spreadtrum Communications, BUPT

R1-2404053 Discussion on AI/ML-based CSI prediction InterDigital, Inc.

R1-2404103 Discussion for further study on AI/ML-based CSI prediction Samsung

R1-2404167 Discussion on CSI prediction vivo

R1-2404274 Discussion on AI based CSI prediction Apple

R1-2404386 Study on AI/ML for CSI prediction CATT

R1-2404422 Discussion on AI/ML-based CSI prediction China Telecom

R1-2404446 Discussion on AI/ML for CSI prediction CMCC

R1-2404492 Discussion on CSI prediction inference in AI/ML Sony

R1-2404527 On AI/ML for CSI prediction Lenovo

R1-2404538 Additional study on AI-enabled CSI prediction NVIDIA

R1-2404547 Study on CSI prediction LG Electronics

R1-2404569 Discussion on AI/ML for CSI prediction SK Telecom

R1-2404584 Discussion on CSI prediction with AI/ML Fujitsu

R1-2404603 Discussion on AI/ML model based CSI prediction Xiaomi

R1-2404653 Discussion on CSI prediction NEC

R1-2404684 AI/ML based CSI Prediction Google

R1-2404702 Discussion on study for AI/ML CSI prediction ZTE

R1-2404744 Discussion on AI/ML for CSI prediction Panasonic

R1-2404810 Varying CSI feedback granularity based on channel conditions Rakuten Mobile, Inc

R1-2404879 Additional study on AI/ML-based CSI prediction OPPO

R1-2404906 AI/ML for CSI Prediction Nokia

R1-2405015 Discussion on AI/ML for CSI prediction AT&T

R1-2405032 Discussion on AI/ML for CSI prediction NTT DOCOMO, INC.

R1-2405088 Additional Study on AI/ML for CSI Prediction MediaTek Inc.

R1-2405125 AI/ML for CSI prediction Mavenir

R1-2405145 Additional study on CSI prediction Qualcomm Incorporated

R1-2405236 Discussion on AI/ML for CSI Prediction CEWiT

R1-2405290 Discussion on study of AIML for CSI prediction IIT Kanpur, Indian Institute of Tech (M)

R1-2405489 Summary #1 of CSI prediction Moderator (LG Electronics)

From Tuesday session

Agreement

For the boundary between Type 3 and Type 1 performance monitoring, the difference is whether UE reports performance metric or performance monitoring output to NW, respectively.

· The monitoring output is determined based on performance metric, and additionally, baseline and/or threshold criterion if configured.

Observation

For CSI prediction using UE-sided model, for performance monitoring, at least following specification impacts are additionally identified compared to that has been captured in TR38.843,

· Type 1

o Definition/configuration of performance metric

o Definition of threshold criterion, if configured

o Definition/configuration and report of monitoring output, and corresponding report mechanism

· Type 2

o Definition/configuration and report of ground truth CSI, and corresponding report mechanism.

· Type 3

o Definition/configuration and report of performance metric, and corresponding report mechanism.

· For all types of performance monitoring, NW indication to the UE of the decision regarding the monitoring action

R1-2405490 Summary #2 of CSI prediction Moderator (LG Electronics)

From Wednesday session

Agreement

For the evaluation of AI/ML-based CSI prediction using localized models in Release 19, regarding training,

The k-th local model is trained on region #B_k (the k-th local region), 1<=k<=N.
The generalized model is trained on Region #A that may be constructed via any of the following methods that is appropriate for the given generalized/local region modeling approach.

Region #A is the same as the union of regions #B_1, …, #B_N.
Region #A is a proper superset of the union of regions #B_1, …, #B_N.
Region #A is generated separately from regions #B_1, …, #B_N.
Note: companies to report which method was used.

For the evaluation of AI/ML-based CSI prediction using localized models in Release 19, regarding testing,

The trained generalized model, local model, and the non-AI/ML benchmark are tested on the regions #B_1, …, #B_N.
In case N>1, when reporting the results, companies may report the performance of the generalized model, the local models, and the non-AI/ML benchmark, by averaging the performance over the regions #B_1,…,B_N. Companies to report the value of N.

R1-2405491 Summary #3 of CSI prediction Moderator (LG Electronics)

R1-2405492 Summary #4 of CSI prediction Moderator (LG Electronics)

From Thursday session

Observation

For the CSI prediction using UE-sided model, till the RAN1#117 meeting, compared to the Benchmark#1 of the nearest historical CSI, in terms of SGCS, from UE speed perspective,

If spatial consistency is not adopted, and if N4=1

For 10km/h UE speed, 1 source [Samsung] observes 9.55% gain
For 30km/h UE speed, 8 sources [Lenovo, Apple, Samsung, China Telecom, Spreadtrum, OPPO, CMCC, Qualcomm] observe 8.5%~20.6% gain and 2 sources [Intel, Fujitsu] observe 23.2%~31.65% gain.
For 60km/h UE speed, 3 sources [Qualcomm, China Telecom, Huawei] observe 2.8%~18% gain

If spatial consistency is adopted, and if N4=1

For 30km/h UE speed, 2 sources [Ericsson, ZTE] observes 17.83%~34.66% gain, 2 sources [vivo, MediaTek] observe 62.8%~76.4% gain
For 60km/h UE speed, 2 sources [Ericsson, MediaTek] observe 16.2~22% gain, 1 source [vivo] observes 90.6% gain
For 120km/h UE speed, 1 source [vivo] observes 68.2% gain

If spatial consistency is not adopted, and if N4=4

· For 30km/h UE speed, 1 source [OPPO] observes 19.7%~25.7% gain

If spatial consistency is adopted, and if N4=4

· For 10km/h UE speed, 1 source [Samsung] observes -1.61%~62.9% gain

· For 30km/h UE speed, 1 source [Ericsson] observes 23%~34% gain, 1 source [MediaTek] observe 20.9%~76.4% gain

· For 60km/h UE speed, 2 sources [Ericsson, MediaTek] observe 5.96%~-22% gain,

If phase discontinuity is modelled, for 30km/h UE speed, 1 source [Fujitsu] observe 52.87% gain.

Note: the above results are based on the following assumptions

· The observation window considers to start as early as 20ms~50ms.

· A future 4ms or 5ms instance from the prediction output is considered for calculating the metric.

· 8 sources [ZTE, Ericsson, Intel, vivo, Fujitsu, Samsung, CATT, MediaTek] consider realistic channel estimation, and other sources consider ideal channel estimation.

· 1 source [Fujitsu] modelled phase discontinuity, and other sources do not consider phase discontinuity modelling.

· 1 source [Qualcomm] considers eigenvector as model input, and other sources considers Raw channel matrix as model input.

· 2 sources [Ericsson, Intel] consider beam-delay domain transformation/antenna-frequency domain transformation as pre/post processing, 1 source [Samsung] considers per layer raw channel matrix after pre-processing, and other sources do not consider pre/post processing.

· The performance metric is SGCS in linear value for layer 1.

Note: N4 refers to the number of predicted CSI instances

Note: Results refer to Table 2-1 of R1-2405492

Observation

For the CSI prediction using UE-sided model, till the RAN1#117 meeting, compared to the Benchmark#2 of non-AI based CSI prediction, in terms of SGCS, from UE speed perspective

If spatial consistency is not adopted, if N4=1

For 10km/h UE speed, 1 source [InterDigital] observes 3% gain
For 30km/h UE speed,

6 sources [Qualcomm, Lenovo, Spreadtrum, Intel, CATT, OPPO] observe 0%~10.7% gain,
2 sources [Fujitsu, InterDigital] observe 25.6%~48% gain
1 source [Apple] observes -2% ~18% gain depending on filter complexity and filter update

For 60km/h UE speed,

1 source [Qualcomm] observes -20.6% gain,
2 sources [Huawei, CATT] observe 3.6%~7.8% gain,
1 source [InterDigital] observes 42% gain

If spatial consistency is adopted, if N4=1

For 30km/h UE speed,

2 sources [Ericsson, MediaTek] observe 0.43%~5% gain,
2 sources [vivo, ZTE] observe 2.54%~26.45%

For 60km/h UE speed,

2 sources [Ericsson, MediaTek] observe -1%~3% gain,
1 source [vivo] observes 48.8% gain

For 120km/h UE speed, 1 source [vivo] observes 20.6% gain

If spatial consistency is not adopted, if N4=4

For 10km/h UE speed, 1 source [InterDigital] observes 1%~5% gain
For 30km/h UE speed, 1 source [InterDigital] observes -14%~48% gain,
For 60km/h UE speed, 1 source [InterDigital] observes -11%~42% gain

If spatial consistency is adopted, if N4=4

For 30km/h UE speed,

1 source [MediaTek] observes 0.43%~0.97% gain
1 source [Ericsson] observes 5%~29% gain

For 60km/h UE speed,

1 source [MediaTek] observes -1.01%~1.52% gain
1 source [Ericsson] observes 3%~16% gain

If phase discontinuity is modelled, for 30km/h UE speed, 2 sources [Fujitsu, vivo] observe 25.6% ~48.8% gain
Note: the above results are based on the following assumptions

The observation window considers to start as early as 15ms~50ms.
A future 4ms or 5ms instance from the prediction output is considered for calculating the metric.
6 sources [ZTE, Ericsson, Intel, vivo, Fujitsu, CATT] consider realistic channel estimation, and other sources consider ideal channel estimation.
2 sources [Fujitsu, vivo] modelled phase discontinuity, and other sources do not consider phase discontinuity modelling.
1 source [Qualcomm] considers eigenvector as model input, and other sources considers Raw channel matrix as model input.
2 source [Ericsson, Intel] considers beam-delay domain transformation/antenna-frequency domain transformation as pre/post processing, and other sources do not consider pre/post processing.
The performance metric is SGCS in linear value for layer 1.

Note: N4 refers to the number of predicted CSI
Note: Results refer to Table 2-3 of R1-2405492

Observation

For the CSI prediction using UE-sided model, till the RAN1#117 meeting, in terms of mean UPT, gains are observed compared to both Benchmark#1 of the nearest historical CSI and Benchmark#2 of a non-AI/ML based CSI prediction approach:

Compared to the benchmark#1 of the nearest historical CSI:

For FTP traffic with low RU (RU<=39%)

For 30km/h UE speed and N4=1

1 source [Ericsson] observes 9% gain.

For 60km/h UE speed, and N4=1

2 sources [Huawei, Ericsson] observe 1.2%~5% gain;

For 30km/h UE speed and N4=4

1 source [Ericsson] observes 7% gain.

For 60km/h UE speed, and N4=4

1 source [Ericsson] observes 5% gain.

For FTP traffic with mid RU (40<=RU<=69%)

For 30km/h UE speed and N4=1

1 source [Ericsson] observes 37% gain.

For 60km/h UE speed, and N4=1

1 source [Huawei] observe 1.8%~3.5% gain;
1 source [Ericsson] observes 21% gain.

For 30km/h UE speed and N4=4

1 source [Ericsson] observes 29% gain.

For 60km/h UE speed, and N4=4

1 source [Ericsson] observes 21% gain.

For FTP traffic with high RU (RU>=70%)

For 60km/h UE speed, and N4=1

1 source [Huawei] observe 2.5%~4.2% gain;

For full buffer traffic:

For 30km/h UE speed and N4=1

1 source [Lenovo] observes 51% gain.
1 source [Fujitsu] observes 27% gain.
1 source [MediaTek] observes 8.7% gain.

For 30km/h UE speed and N4=4

1 source [Fujitsu] observes 11.6% gain.

Compared to the benchmark#2 of non-AI/ML based CSI prediction:

For FTP traffic, with low RU (RU<=39%)

For 30km/h UE speed and N4=1,

1 source [Ericsson] observes 9% gain.
1 source [CATT] observes -2.1% gain.

For 60km/h UE speed, and N4=1

1 source [Huawei] observes 0.7%~0.9% gain;
1 source [Ericsson] observes 11% gain.
1 source [CATT] observes -6.1% gain

For 30km/h UE speed and N4=4,

1 source [Ericsson] observes 13% gain.
1 source [InterDigital] observes 2.1% gain.
1 source [MediaTek] observes 0.02% gain.

For 60km/h UE speed, and N4=4

1 source [Ericsson, InterDigital] observes 13%
1 source [MediaTek] observes 0.14% gain
1 source [Ericsson, InterDigital] observes -13.1%

For FTP traffic, with mid RU (40<=RU<=69%)

For 30km/h UE speed and N4=1,

1 source [Ericsson] observes 24% gain.

For 60km/h UE speed, and N4=1

1 source [Huawei] observes 2.3%~3.1% gain;
1 source [Ericsson] observes 31% gain.

For 30km/h UE speed and N4=4,

1 source [Ericsson] observes 35% gain.
2 sources [MediaTek, InterDigital] observe -0.25%~2.5% gain.

For 60km/h UE speed, and N4=4

1 source [Ericsson] observes 32% gain.
1 source [MediaTek] observes 0.25% gain.
1 source [InterDigital] observes -19.6% gain.

For FTP traffic, with high RU (RU>=70%)

For 60km/h UE speed, and N4=1

1 source [Huawei] observes 2%~2.5% gain;

For 30km/h UE speed and N4=4,

2 sources [InterDigital, MediaTek] observes 0.11%~5.7% gain.

For 60km/h UE speed, and N4=4

1 source [InterDigital] observes -17.2% gain.
1 source [MediaTek] observes 0.92% gain.

For full buffer traffic:

For 30km/h UE speed and N4=1

1 source [Lenovo] observes 24% gain.
1 source [Fujitsu] observes 9.7% gain.
2 sources [CATT, MediaTek] observe 0.6~1.2% gain.

For 60km/h UE speed, and N4=1

1 source [CATT] observes 0.2% gain
1 source [vivo] observes 20.6% gain

For 30km/h UE speed and N4=3 or 4

1 source [Fujitsu] observes 7% gain.
1 source [vivo] observes 24.7% gain with phase discontinuity modelling.

For 60km/h UE speed and N4=3

1 source [vivo] observes 41.3% gain with phase discontinuity modelling.

Note: the above results are based on the following assumptions

The observation window considers to start as early as 15ms~50ms.
A future 4ms ~ 20ms instance from the prediction output is considered for calculating the metric.
Raw channel matrix is considered as model input
The performance metric is mean UPT for Max rank 1.
1 source [Ericsson] considers beam-delay domain transformation/antenna-frequency domain transformation as pre/post processing, and other sources considers no pre/post processing.
3 sources [vivo, Ericsson, MediaTek] consider spatial consistency, and other sources do not consider spatial consistency.
4 sources [Ericsson, Fujitsu, CATT, MediaTek] consider realistic channel estimation, and other sources consider ideal channel estimation.
1 source [vivo] are modelled phase discontinuity, and other sources do not consider phase discontinuity

Note: N4 refers to the number of predicted CSI instances
Note: Results refer to Table 2-5/2-4/2-4/2-8 of R1-2405492

Observation

For the CSI prediction using UE-sided model, till the RAN1#117 meeting, in terms of 5% UE UPT, gains are observed compared to both Benchmark#1 of the nearest historical CSI and Benchmark#2 of a non-AI/ML based CSI prediction approach:

Compared to the benchmark#1 of the nearest historical CSI:

For FTP traffic with low RU (RU<=39%)

For 30km/h UE speed and N4=1

1 source [Ericsson] observes 27% gain.

For 60km/h UE speed, and N4=1

2 sources [Huawei, Ericsson] observe 4.5%~18.3% gain;

For 30km/h UE speed and N4=4

1 source [Ericsson] observes 14% gain.

For 60km/h UE speed, and N4=4

1 source [Ericsson] observes 4% gain.

For FTP traffic with mid RU (40<=RU<=69%)

For 30km/h UE speed and N4=1

1 source [Ericsson] observes 100% gain.

For 60km/h UE speed, and N4=1

1 source [Huawei] observe 8.6%~11.3% gain;
1 source [Ericsson] observes 45% gain.

For 30km/h UE speed and N4=4

1 source [Ericsson] observes 77% gain.

For 60km/h UE speed, and N4=4

1 source [Ericsson] observes 26% gain.

For FTP traffic with high RU (RU>=70%)

For 60km/h UE speed, and N4=1

1 source [Huawei] observe 13.4%~17.8% gain;

For full buffer traffic:

For 30km/h UE speed and N4=1

1 source [Lenovo] observes 10.5% gain.
1 source [Fujitsu] observes 9.9% gain.
1 source [MediaTek] observes 7.7% gain.

For 30km/h UE speed and N4=4

1 source [Fujitsu] observes 2.1% gain.

Compared to the benchmark#2 of non-AI/ML based CSI prediction:

For FTP traffic, with low RU (RU<=39%)

For 30km/h UE speed and N4=1,

1 source [Ericsson] observes 18% gain.
1 source [CATT] observes 50.1% gain.

For 60km/h UE speed, and N4=1

1 source [Huawei] observes 2.5%~5.2% gain;
1 source [Ericsson] observes 17% gain.
1 source [CATT] observes 47.1% gain

For 30km/h UE speed and N4=4,

1 source [Ericsson] observes 23% gain.
1 source [InterDigital] observes 5.7% gain.

For 60km/h UE speed, and N4=4

2 sources [Ericsson, InterDigital] observe 9.5%~% 19%gain.

For FTP traffic, with mid RU (40<=RU<=69%)

For 30km/h UE speed and N4=1,

1 source [Ericsson] observes 46% gain.

For 60km/h UE speed, and N4=1

1 source [Huawei] observes 7%~8.6% gain;
1 source [Ericsson] observes 66% gain.

For 30km/h UE speed and N4=4,

1 source [Ericsson] observes 73% gain.
1 source [InterDigital] observes 6.8% gain.

For 60km/h UE speed, and N4=4

1 source [Ericsson] observes 56% gain.
1 source [InterDigital] observes 27.2% gain.

For FTP traffic, with high RU (RU>=70%)

For 60km/h UE speed, and N4=1

1 source [Huawei] observes 6.7%~14.8% gain;

For 30km/h UE speed and N4=4,

1 source [InterDigital] observes 28.6% gain.

For 60km/h UE speed, and N4=4

1 source [InterDigital] observes 27.2% gain.

For full buffer traffic:

For 30km/h UE speed and N4=1

3 sources [Lenovo, Fujitsu, CATT] observe 0.2%~6% gain.
1 source [MediaTek] observes -2% gain.

For 60km/h UE speed, and N4=1

1 source [CATT] observes 0.4% gain

For 30km/h UE speed and N4=3 or 4

1 source [Fujitsu] observes 6.3% gain.
1 source [vivo] observes 81.9% gain with phase discontinuity modelling.

For 60km/h UE speed and N4=3

1 source [vivo] observes 48.9% gain with phase discontinuity modelling.

Note: the above results are based on the following assumptions

The observation window considers to start as early as 15ms~50ms.
A future 4ms ~ 20ms instance from the prediction output is considered for calculating the metric.
Raw channel matrix is considered as model input
The performance metric is mean UPT for Max rank 1.
1 source [Ericsson] considers beam-delay domain transformation/antenna-frequency domain transformation as pre/post processing, and other sources considers no pre/post processing.
3 sources [vivo, Ericsson, MediaTek] consider spatial consistency, and other sources do not consider spatial consistency.
4 sources [Ericsson, Fujitsu, CATT, MediaTek] consider realistic channel estimation, and other sources consider ideal channel estimation.
1 source [vivo] are modelled phase discontinuity, and other sources do not consider phase discontinuity

Note: N4 refers to the number of predicted CSI instances
Note: Results refer to Table 2-5/2-4/2-4/2-8 of R1-2405492

Observation

For the generalization verification of CSI prediction using UE sided model over various UE speeds, till the RAN1#117 meeting, compared to the generalization Case 1 where the AI/ML model is trained with dataset subject to a certain UE speed#B and applied for inference with a same UE speed#B,

For generalization Case 2, generalized performance may be achieved for some certain combinations of UE speed#A and UE speed#B but not for others:

If UE speed#B is 10 km/h and

UE speed#A is 30 km/h or 120km/h, 2 sources [Fujitsu, MediaTek] observe a generalized performance of less than -5.5% degradation.
UE speed#A is 60 km/h, 1 source [CMCC] observes -26.79% degradation.

If UE speed#B is 30 km/h and

UE speed#A is 60km/h, 4 sources [Huawei, CATT, Ericsson, vivo] observe a generalized performance of -11.4%~-2.7% degradation and 1 source [CMCC] observes a generalized performance of -25.6%~-32% degradation.
UE speed#A is 10km/h or 120km/h, 3 sources [CMCC, MediaTek, Fujitsu] observe a generalized performance of -51.5%~-72.37% degradation.

If UE speed#B is 60 km/h and

UE speed#A is 30km/h, 1 source [CATT] observes a generalized performance of -1.9% degradation and 5 sources [Huawei, Fujitsu, MediaTek, Ericsson, vivo] observe a generalized performance of -28.6%~-56.3% degradation

If UE speed#B is 120 km/h and

UE speed#A is 30km/h, 1 source [MediaTek] observes a generalized performance of -56.3% degradation

For generalization Case 3, generalized performance of the AI/ML model can be achieved in general (0%~-3.63% loss) for UE speed#B subject to any of 10 km/h, 30 km/h, 60 km/h and 120 km/h, if the training dataset is constructed with data samples subject to multiple UE speeds including UE speed#B, as observed by 6 sources [Fujitsu, Huawei, CATT, vivo, Apple, Ericsson]

If UE speed#B is 10 km/h

2 sources [Fujitsu, MediaTek] observe a generalized performance of less than -0.2% degradation, and 1 source [CMCC] observes -16.87% degradation.

If UE speed#B is 30 km/h

7 sources [Huawei, CATT, vivo, Apple, Fujitsu, Ericsson, MediaTek] observe a generalized performance of less than -2.77% degradation, 1 source [CMCC] observes a generalized performance of -15.44% degradation.

If UE speed#B is 60 km/h and

6 sources [Huawei, CATT, vivo, Apple, Fujitsu, Ericsson] observe a generalized performance of less than -3.63% degradation, 2 sources [CMCC, MediaTek] observe a generalized performance of -6.77%~-13.5% degradation.

If UE speed#B is 120 km/h and

1 source [MediaTek] observes a generalized performance of -43.6% degradation

Note: For generalization Case 3, 2 sources [CMCC, MediaTek] observe performance degradations (-13.5%~-43.6% loss) for UE speed#B subject to 10 km/h, 30 km/h, 60 km/h, 120 km/h, but compared with generalization Case 2, in general the performance are still improved.

Note: the above results are based on the following assumptions besides the assumptions of the agreed EVM table

Raw channel matrix is used as the model input.
The performance metric is SGCS in linear value for layer 1/2/3/4.
3 sources [vivo, Ericsson, MediaTek] consider spatial consistency. Other sources do not consider spatial consistency.
1 source [Ericsson] considers beam-delay domain transformation/antenna-frequency domain transformation as pre/post processing, and other sources considers no pre/post processing.

Note: Results refer to Table 3-2 of R1-2405492

Final summary in R1-2405683.

9.1.3.2 CSI compression

R1-2403867 Discussion on additional study on AI/ML for NR air interface for CSI compression FUTUREWEI

R1-2403897 AI/ML for CSI Compression Tejas Networks Limited

R1-2403910 AI/ML for CSI compression Ericsson

R1-2403932 Discussion on AI/ML for CSI compression Huawei, HiSilicon

R1-2403976 AI/ML for CSI compression Intel Corporation

R1-2404000 Discussion on AI/ML CSI compression TCL

R1-2404017 Discussion on AIML for CSI compression Spreadtrum Communications, BUPT

R1-2404054 Discussion on AI/ML-based CSI compression InterDigital, Inc.

R1-2404104 Discussion for further study on AI/ML-based CSI compression Samsung

R1-2404168 Discussion on CSI compression vivo

R1-2404275 Discussion on AI based CSI compression Apple

R1-2404387 Study on AI/ML for CSI compression CATT

R1-2404423 Discussion on AI/ML-based CSI compression China Telecom

R1-2404447 Discussion on AI/ML for CSI compression CMCC

R1-2404493 Discussion on CSI compression Sony

R1-2404528 On AI/ML for CSI compression Lenovo

R1-2404539 Additional study on AI-enabled CSI compression NVIDIA

R1-2404548 Study on CSI compression LG Electronics

R1-2404571 Discussion on AI/ML for CSI compression SK Telecom

R1-2404585 Discussion on CSI compression with AI/ML Fujitsu

R1-2404604 Discussion on AI/ML model based CSI compression Xiaomi

R1-2404654 Discussion on CSI compression NEC

R1-2404685 AI/ML based CSI Compression Google

R1-2404703 Discussion on study for AI/ML CSI compression ZTE

R1-2404722 Discussions on AI/ML for CSI feedback CAICT

R1-2404745 Discussion on AI/ML for CSI compression Panasonic

R1-2404768 Discussion on AI/ML for CSI compression ETRI

R1-2404880 Additional study on AI/ML-based CSI compression OPPO

R1-2404907 AI/ML for CSI Compression Nokia

R1-2405016 Discussion on AI/ML for CSI compression AT&T

R1-2405033 Discussion on AI/ML for CSI compression NTT DOCOMO, INC.

R1-2405089 Additional Study on AI/ML for CSI Compression MediaTek Inc.

R1-2405116 Discussion on additional study of AI/ML for CSI Compression IIT Kanpur, Indian Institute of Tech (M)

R1-2405146 Additional study on CSI compression Qualcomm Incorporated

R1-2405210 Discussion on the AI/ML for CSI Compression Fraunhofer IIS

R1-2405237 Discussion on AI/ML for CSI Compression CEWiT

R1-2405414 Summary#1 of Additional study on AI/ML for NR air interface: CSI compression Moderator (Qualcomm)

From Monday session

Conclusion

Standardized signalling, if feasible and specified, can be used for parameter / model exchange in option 3a/5a and 3b to alleviate/resolve the inter-vendor training collaboration complexity.

Standardized signalling may be reused for exchanging CSI generation part, CSI reconstruction part, or both, etc, when necessary and feasible.
Standardized signalling may be over-the-air, or other approaches.

Standardized signalling, if feasible and specified, can be used for dataset exchange in option 4 to alleviate/resolve the inter-vendor training collaboration complexity.

Standardized signalling may be reused for dataset exchanging, when necessary and feasible.
Standardized signalling may be over-the-air, or other approaches.

Note: feasibility will be discussed separately.

R1-2405415 Summary#2 of Additional study on AI/ML for NR air interface: CSI compression Moderator (Qualcomm)

From Tuesday session

Agreement

For option 3a/3b/4/5a and their sub-options, at least the following potential specification impacts have been identified. Further study the necessity, feasibility, their specification impact.

· Exchange

o Parameter / model exchange methods, format/contents, and related spec impacts (3a/3b/5a)

o Dataset exchange methods, format/type/contents of data/dataset, and related spec impacts (4)

o Additional information, if necessary, that may be shared from the NW-side to help UE-side offline engineering and provide performance guidance (3a/5a/4)

§ Performance target (3a/5a/4)

§ Dataset or information related to collecting dataset (3a/5a)

§ Any other additional information

· Model pairing (3a/3b/4/5a)

· UE capability (3a/3b/4/5a)

· Model related aspects, such as scalability (e.g., payload sizes, antenna ports, bandwidth), rank and layer handling (3a/3b/4/5a)

· Quantization of feedback (3a/3b/4/5a)

· Model structure details (3a/3b)

Note: Option 3a/4/5a and option 3b serve two different deployment time scales, UE capabilities, device-side optimizations, and training methods, and therefore may be complementary to each other, with potential specification of both.

· Specification of option 1, if needed from RAN1, can reuse specification of option 3a/3b, with the additional specification of parameters.

Agreement

For option 1 / 3 / 4 / 5 and their sub-options, study mechanisms (e.g., post-deployment performance monitoring) for identifying the cause (e.g., NW side, UE side, data drift) of the performance degradation to guarantee good performance in the field.

R1-2405416 Summary#3 of Additional study on AI/ML for NR air interface: CSI compression Moderator (Qualcomm)

From Wednesday session

Agreement

For temporal domain aspects Case 3/4, change the small / medium / large payload region definition as follows:

Note: X, Y, Z, A, B, and C are feedback overhead rates in bits per time unit of 5ms.

Note: For X, Y, and Z, α=[2] for rank=1/2 and α=[4] for rank=4

Note: For A, B, and C, β=[0.5] for rank=1 and β=[0.75] for rank=2/4

Agreement

For the evaluation of temporal domain aspects of AI/ML-based CSI compression (Cases 1-5), in addition to FLOPs, also consider FLOPs per normalized time unit. Use 5msec as the normalized time unit.

Agreement

In the results template for capturing the evaluation of temporal domain aspects Case 3/4 of AI/ML based CSI compression, regarding the “upper bound”, capture both of the following:

· upper bound based on ideal CSI prediction and without CSI compression

· upper bound based on benchmark CSI prediction and without CSI compression

Agreement

For the evaluation of AI/ML-based CSI compression using localized models in Release 19, regarding training,

The k-th local model is trained on region #B_k (the k-th local region), 1<=k<=N.
The generalized model is trained on Region #A that may be constructed via any of the following methods that is appropriate for the given generalized/local region modeling approach.

Region #A is the same as the union of regions #B_1, …, #B_N.
Region #A is a proper superset of the union of regions #B_1, …, #B_N.
Region #A is generated separately from regions #B_1, …, #B_N.
Note: companies to report which method was used.

For the evaluation of AI/ML-based CSI compression using localized models in Release 19, regarding testing,

· The trained generalized model, local model, and the non-AI/ML benchmark are tested on the regions #B_1, …, #B_N.

· In case N>1, when reporting the results, companies may report the performance of the generalized model, the local models, and the non-AI/ML benchmark, by averaging the performance over the regions #B_1,…,B_N. Companies to report the value of N.

Agreement

For collecting evaluation results for temporal domain aspects of AI/ML-based CSI compression using localized models, use the same results template used to collect evaluation results for AI/ML-based CSI compression using localized models

· Adding the same temporal setting that is used for results template used to collect evaluation results for temporal domain compression Case 1/2/5.

Temporal setting	Temporal domain aspect Case 1-5
	CSI-RS configuration: periodic or aperiodic For periodic: periodicity For aperiodic: # of resources K in the CSI-RS burst / time internal m in msec
	CSI reporting periodicity
	Usage of historical CSI at UE side: number / time distance
	Usage of historical CSI at NW side: number / time distance
	Prediction window: number / time distance between prediction instances / distance from the last observation instance to the 1st prediction instance (Only applicable to Case 3,4)

R1-2405417 Summary#4 of Additional study on AI/ML for NR air interface: CSI compression Moderator (Qualcomm)

From Thursday session

Agreement

Further study following monitoring options in Rel-19, including the necessity and feasibility,

NW-side monitoring, considering overhead, latency, complexity, monitoring accuracy, UE capability

Based on the target CSI reported by the UE via legacy eT2 codebook or eT2-like high-resolution codebook (Case 1)
SRS-based monitoring

UE-side monitoring, considering overhead, latency, complexity, monitoring accuracy, UE capability

Based on the output of the CSI reconstruction model at the UE (Case 2-1)

Note: CSI reconstruction model at the UE-side can be the same as the actual CSI reconstruction model used at the NW-side, a reference model provided by NW, or a proxy model developed by the UE side.

Via direct estimation of intermediate KPI (e.g., SGCS) without reconstructing a target CSI (Case 2-2)
Via estimation of monitoring output other than intermediate KPI without reconstructing a target CSI
Based on precoded RS (e.g., CSI-RS, DMRS) transmitted from NW based on the output of the CSI reconstruction model
Based on the output of the CSI reconstruction model indicated by the NW via legacy eT2 codebook or eT2-like high-resolution codebook

Regarding monitoring metrics:

Monitoring accuracy also includes generalization considerations, if applicable.
Complexity also includes LCM complexity, if applicable.
Monitoring overhead, latency, complexity, and accuracy analysis may have to consider using at N>1 CSI feedback occasions.
Testability of UE reported metrics

Discussion may include the following aspects:

Consideration of Options 1-5 and their sub-options for alleviating / resolving the issues related to inter-vendor training collaboration
Temporal domain aspects of CSI compression
How the above monitoring approaches or combination of them may help identifying the cause (e.g., NW side, UE side, data drift) of the performance degradation

Note: for UE-side monitoring, the final reported monitoring output, if specified, may be different, e.g., be further derived based on the output of the above approaches.

Note: implementation-based monitoring solutions can be considered in assessing the necessity of the above monitoring approaches.

Agreement

For temporal domain aspects Case 3 and 4, study the impact on LCM aspects of separate prediction and compression, and joint prediction and compression.

Note: Observations of companies results till RAN1#117 are captured in FL summary R1-2405419.

Final summary in R1-2405419.

9.1.3.33 Other aspects of AI/ML model and data

Including model identification/procedure, collection of UE-sided model training data, and model transfer/delivery

R1-2403868 Discussion on other aspects of AI/ML model and data on AI/ML for NR air-interface FUTUREWEI

R1-2403915 Discussion on other aspects of AI/ML Ericsson

R1-2403933 Discussion on other aspects of the additional study for AI/ML Huawei, HiSilicon

R1-2403977 Other study aspects of AI/ML for air interface Intel Corporation

R1-2404018 Discussion on other aspects of AI/ML model and data Spreadtrum Communications

R1-2404055 Discussion on other aspects of AI/ML model and data InterDigital, Inc.

R1-2404105 Discussion for further study on other aspects of AI/ML model and data Samsung

R1-2404169 Other aspects of AI/ML model and data vivo

R1-2404276 Discussion on other aspects of AI/ML model and data Apple

R1-2404388 Study on AI/ML for other aspects of model and data CATT, CICTCI

R1-2404448 Discussion on other aspects of AI/ML model and data CMCC

R1-2404529 On aspects of AI/ML model and data framework Lenovo

R1-2404540 Additional study on other aspects of AI model and data NVIDIA

R1-2404549 Discussion on other aspects of AI/ML model and data LG Electronics

R1-2404586 Discussion on other aspects of AI/ML model and data Fujitsu

R1-2404605 Further study on AI/ML model and data Xiaomi

R1-2404656 Discussion on other aspects of AI/ML model and data NEC

R1-2404686 AI/ML Model and Data Google

R1-2404704 Discussion on study for other aspects of AI/ML model and data ZTE

R1-2404756 Discussion on other aspects for AI/ML for air interface Panasonic

R1-2404764 View on AI/ML model and data MediaTek Korea Inc.

R1-2404769 Discussion on other aspects of AI/ML model and data ETRI

R1-2404881 Additional study on other aspects of AI/ML model and data OPPO

R1-2404908 Other Aspects of AI/ML Model and Data Nokia

R1-2405017 Other Aspects of AI/ML framework AT&T

R1-2405034 Discussion on other aspects of AI/ML model and data NTT DOCOMO, INC.

R1-2405147 Other aspects of AI/ML model and data Qualcomm Incorporated

R1-2405212 Discussion on other aspects of AI/ML model and data Continental Automotive

R1-2405304 Discussion on other aspects of AI/ML model and data IIT Kanpur, Indian Institute of Tech (M)

R1-2405501 Summary #1 for other aspects of AI/ML model and data Moderator (OPPO)

From Tuesday session

Working Assumption

Regarding the associated ID for Rel-19, the UE assumes that NW-side additional conditions with the same associated ID are consistent at least within a cell.

FFS: whether/how UE assumption can be applicable for multiple cells (including the feasibility study).

R1-2405502 Summary #2 for other aspects of AI/ML model and data Moderator (OPPO)

From Wednesday session

Agreement

From RAN1 perspective, for model delivery/transfer Case z4, further study the following alternatives (including the necessity/feasibility/benefits):

· Alt. A

o Step A-1: UE reports the supported known model structure(s) to network

o Step A-2: NW transfers to UE the parameters for one or more of supported known model structure(s) reported in Step A-1

o FFS: whether some additional step(s), and/or whether other information is needed

· Alt. B

o Step B-0: UE reports to NW its support of model transfer/delivery case z4

o Note: Step B-0 may be before or after Step B-1, or not necessary

o Step B-1: NW indicates to UE the candidate known model structure(s)

o Step B-2: UE reports to NW which model structure(s) out of the candidate known model structure(s) indicated in Step B-1 is supported

o Step B-3: NW transfers to UE the parameters for one or more of supported known model structure(s) reported in Step B-2

o FFS: whether some additional step(s), and/or whether other information is needed

· Note: Other alternative(s) is not precluded

· Note: Other method(s) of parameter exchange from NW to UE side is a separate discussion.

R1-2405503 Summary #3 for other aspects of AI/ML model and data Moderator (OPPO)

Presented in Thursday session

R1-2405504 Summary #4 for other aspects of AI/ML model and data Moderator (OPPO)

From Friday session

Agreement

From RAN1 perspective, for UE part of two-sided model, further study the following example of MI-Option2 (including the feasibility/necessity)

· AI-Example2-1

o A: A dataset is transferred from the NW/NW-side to UE/UE-side via standardized signaling.

§ Note: RAN1 study of Step A only focuses on RAN1 aspect of the dataset transfer from NW to UE. Other solution for dataset exchange is out of RAN1 scope.

o B: UE part of two-sided model(s) is(are) developed based on at least the above dataset.

o C: UE reports information of its UE part of two-sided model(s) corresponding to the above dataset to the NW.

o FFS: How model ID is determined/assigned for each AI/ML model (including relationship between dataset and model ID)

o Note: Some step(s) may not be needed for MI-Option2

· Note: The above example is based on the assumption of NW-first training. It is separate discussion for the assumption of UE-first training.

· Note: The study should consider the impact on inter-vendor collaboration, at least including complexity, performance, interoperability in RAN4/testing related aspects and feasibility.

· FFS: whether/how to consider UE-side additional condition(s) for the dataset

Final summary in R1-2405505.

RAN1#118

9.1 Artificial Intelligence (AI)/Machine Learning (ML) for NR Air Interface

Please refer to RP-240774 for detailed scope of the WI.

R1-2407478 Session notes for 9.1 (AI/ML for NR Air Interface) Ad-Hoc Chair (CMCC)

Friday decision: The session notes are endorsed and contents reflected below.

[118-R19-AI/ML] – Taesang (Qualcomm)

Email discussion on Rel-19 AI/ML

- To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc

R1-2406259 Draft TP to capture the output of Agenda item 9.1.3.3 (to collect comments) OPPO

Friday session

[Post-118-AI/ML-01] – Taesang (Qualcomm)

Email discussion for endorsement of an updated version of TR 38.843, from August 26 to 30.

9.1.1 Specification support for beam management

R1-2405808 Discussion on specification support for AI/ML-based beam management FUTUREWEI

R1-2405899 Discussion on AIML for beam management Spreadtrum Communications

R1-2405944 Specification Support for AI/ML for Beam Management Kyocera

R1-2405950 AI/ML based Beam Management Google

R1-2405963 AI/ML for Beam Management Tejas Networks Limited

R1-2405975 Discussion on specification support for beam management CMCC

R1-2406014 Specification support for AI/ML for beam management Intel Corporation

R1-2406054 Discussion on AI/ML-based beam management ZTE Corporation, Sanechips

R1-2406141 AI/ML for beam management Ericsson

R1-2406172 Specification support for beam management vivo

R1-2406254 On specification for AI/ML-based beam management OPPO

R1-2406269 Specification support for beam management Xiaomi

R1-2406305 Discussion on specification support on AI/ML for beam management Fujitsu

R1-2406353 Specification support for AI/ML-based beam management CATT

R1-2406395 Discussion on AIML Beam Management TCL

R1-2406416 Discussions on AI/ML for beam management LG Electronics

R1-2406440 AI/ML specification support for beam management Lenovo

R1-2406463 Discussions on AI/ML for beam management Sony

R1-2406492 Specification support for AI-enabled beam management NVIDIA

R1-2406497 Discussion on AI/ML for beam management InterDigital, Inc.

R1-2406526 Discussion on specification support for beam management Panasonic

R1-2406541 Discussion on specification support for beam management NEC

R1-2406571 Discussion on AI/ML based beam management Hyundai Motor Company

R1-2406586 AI/ML for Beam Management Nokia

R1-2406593 Discussions on specification support for beam management Ruijie Networks Co. Ltd

R1-2406637 Discussion for supporting AI/ML based beam management Samsung

R1-2406699 Discussion on specification support for AI/ML beam management Transsion Holdings

R1-2406718 Discussion on specification support for beam management ETRI

R1-2406765 Discussion on specification support for AIML-based beam management MediaTek Inc.

R1-2406826 Discussion on AI/ML beam management Apple

R1-2406884 Discussion on AI/ML based beam management KT Corp.

R1-2406888 AI/ML for Beam Management Meta Ireland

R1-2406894 Discussions on AI/ML for beam management CAICT

R1-2406920 Discussion on AI/ML for beam management NTT DOCOMO, INC.

R1-2406969 Discussion on specification support for beam management Sharp

R1-2406977 Discussion on beam management for AI/ML Huawei, HiSilicon

R1-2407019 Specification support for AI-ML-based beam management Qualcomm Incorporated

R1-2407064 Discussions on Specification Support of AI/ML for Beam Management Indian Institute of Tech (M), IIT Kanpur

R1-2407109 Specification support for beam management Fraunhofer HHI, Fraunhofer IIS

R1-2407116 A Novel Model-ID Free Approach for Interoperability in AI/ML Beam Management Use Cases NTU

R1-2407120 Specification support for AI/ML beam management ITL

R1-2407142 Specification support for beam management KDDI Corporation

R1-2407320 FL summary #0 for AI/ML in beam management Moderator (Samsung)

Presented in Monday session.

R1-2407321 FL summary #1 for AI/ML in beam management Moderator (Samsung)

Presented in Tuesday session.

R1-2407322 FL summary #2 for AI/ML in beam management Moderator (Samsung)

From Wednesday session

Agreement

For UE sided model in beam management, support associated ID

· [Working Assumption]

o The associated ID at least can be configured within CSI framework

§ FFS on details

§ FFS on whether/how to configure/indicate the associated ID via other signal(s) and/or in other procedure(s)/framework(s)

· UE may assume the similar properties of a DL Tx beam or beam set/list associated with the same associated ID

o FFS: whether/how to define similar properties of a DL Tx beam or beam set/list

Agreement

For UE-sided model, for the quantization of a RSRP value at least for the report of inference results, support

Support differential RSRP reporting with legacy quantization step and range for L1-RSRP reporting

For BM-Case 1, support differential RSRP report among multiple beams
For BM-Case 2, support differential RSRP report among multiple beams over multiple time instances

FFS details

R1-2407323 FL summary #3 for AI/ML in beam management Moderator (Samsung)

From Thursday session

Agreement

For UE-sided model at least for BM Case-1, for inference results report

Two resource sets can be configured for Set A and Set B separately in the CSI report configuration for the report

FFS whether support only resource set for Set B is configured

UE performs measurement on the resource set for Set B for inference, and UE is not expected to measure resource set for Set A for inference,

· The beam information in the inference report refers to the resource set for Set A

Agreement

For BM-Case1 and BM-Case2 with a UE-sided AI/ML model, for Option 2 (UE-assisted performance monitoring), further study at least the following alternatives, including:

Alt 1: Top 1 or Top K beam prediction accuracy (with or without margin) by comparing the prediction results and the Top 1 or Top K beam based on the measurements from a resource set/resources for monitoring
Alt 2: The L1-RSRP difference information based on actual measurement of the L1-RSRP of one or more of Top K predicted beam, and L1-RSRP measurements from a resource set/resources for monitoring
Alt 3: The RSRP difference information between the predicted RSRP and measured L1-RSRP of corresponding beam(s) of a resource set/resources for monitoring

Note: resources for Set B for monitoring are not precluded and can be study.
Note: this is only applicable when the model can predict RSRP

Alt 4: The probability information of the predicted beam(s) to be the Top 1 or Top K beam

Note: this is only applicable when the model can generate probability information

FFS: for Alt 1/2/3, on other details including how to configure the resource set/resources for monitoring, including

E.g. whether/how to use full set of Set A for measurement. If not, whether/how to obtain the measurement of the predicted Top 1 or Top K beam for calculating the prediction accuracy or the RSRP difference.

For all alternatives, study whether the performance information is calculated per sample (one-shot), or per set of samples (window)

R1-2407324 FL summary #4 for AI/ML in beam management Moderator (Samsung)

From Friday session

Agreement

For UE-sided model for BM-Case 2, for inference results report, support to configure UE with N future time instance(s) for inference by NW when applicable

FFS: how to determinate reference time for the time instance(s).
FFS: duration values of the N time instance(s) that can be predicted.

Final summary in R1-2407554.

9.1.2 Specification support for positioning accuracy enhancement

R1-2405945 AI/ML for Positioning Accuracy Enhancement Ericsson Inc.

R1-2405951 AI/ML based Positioning Google

R1-2405976 Discussion on specification support for positioning accuracy enhancement CMCC

R1-2406015 Specification support for AI/ML for positioning accuracy enhancement Intel Corporation

R1-2406055 Discussion on AI/ML-based positioning enhancement ZTE Corporation, Pengcheng Laboratory

R1-2406173 Specification support for positioning accuracy enhancement vivo

R1-2406206 Discussion on support for AIML positioning InterDigital, Inc.

R1-2406255 On specification for AI/ML-based positioning accuracy enhancements OPPO

R1-2406270 Discussion on AI/ML-based positioning accuracy enhancement Xiaomi

R1-2406306 Discussion on specification support for AI/ML positioning accuracy enhancement Fujitsu

R1-2406354 Specification support for AI/ML-based positioning CATT, CICTCI

R1-2406394 Discussion on specification support for positioning accuracy enhancement TCL

R1-2406441 Specification impacts for AI/ML Positioning Lenovo

R1-2406464 Discussion on AI/ML for positioning accuracy enhancement Sony

R1-2406493 Specification support for AI-enabled positioning NVIDIA

R1-2406536 Discussion on specification support for AIML based positioning accuracy enhancement NEC

R1-2406587 AI/ML for Positioning Accuracy Enhancement Nokia

R1-2406594 Discussions on specification support for positioning accuracy enhancement Ruijie Networks Co. Ltd

R1-2406638 Discussion for supporting AI/ML based positioning accuracy enhancement Samsung

R1-2406711 AI/ML positioning accuracy enhancement Fraunhofer IIS, Fraunhofer HHI

R1-2406719 Discussion on specification support for positioning accuracy enhancement ETRI

R1-2406827 Discussion on Specification Support for AI/ML-based positioning Apple

R1-2406921 Discussion on AI/ML for positioning accuracy enhancement NTT DOCOMO, INC.

R1-2406970 Discussion on specification support for AI/ML based positioning accuracy enhancements Sharp

R1-2406978 Discussion on AI/ML for positioning accuracy enhancement Huawei, HiSilicon

R1-2407020 Specification support for AI-ML-based positioning accuracy enhancement Qualcomm Incorporated

R1-2407063 Discussion on Specification Support of AI/ML for Positioning Accuracy Enhancement Indian Institute of Tech (M), IIT Kanpur

R1-2407076 Discussion on specification support for AI/ML positioning accuracy enhancement CEWiT

R1-2407105 Design for AI/ML based positioning MediaTek Korea Inc.

R1-2407166 Discussions on positioning accuracy enhancement for AI/ML ITL

R1-2407267 Summary #1 of specification support for positioning accuracy enhancement Moderator (Ericsson)

From Monday session

Agreement

For AI/ML positioning Case 3a, for performance monitoring metric calculation in label-based monitoring, from RAN1 perspective, Option A and Option B are feasible,

· Option A. NG-RAN node performs monitoring metric calculation for its own model.

· Option B. LMF performs monitoring metric calculation for the model located at the NG-RAN node.

Note: Final selection of Option A and Option B is out of RAN1 scope. Potential support of Option A and/or Option B is pending RAN3 confirmation.

Note: Exact method to perform monitoring metric calculation is up to implementation.

Note: For Option A, RAN1 assumes that user data privacy needs to be preserved.

R1-2407268 Summary #2 of specification support for positioning accuracy enhancement Moderator (Ericsson)

From Tuesday session

Conclusion

For model performance monitoring of AI/ML positioning Case 1, for model performance monitoring metric calculation in label-based model monitoring,

· Option A-4 can be realized by implementation in a manner transparent to specification if the PRU sends information to the target UE side in a proprietary method. No further discussion on Option A-4.

Agreement

For training data collection of AI/ML based positioning case 3b, for time stamp of channel measurement,

· For channel measurement generated by TRP/gNB, existing IE “Time Stamp” in TS 38.455 can be reused from RAN1 perspective.

Note: Purpose, such as above “training data collection", will not necessarily be specified in RAN 1 specifications.

Agreement

For training data collection of Case 1 and 2a, in terms of DL PRS configuration for collecting training data, RAN1 study the following options on assistance data, using legacy mechanisms as a starting point:

· Option A. (UE initiated) UE makes a request to LMF on the preferred DL PRS configuration for training data collection, e.g., on-demand PRS. LMF makes the decision on determining the DL PRS configuration for training data collection and provides the assistance data to the UE.

· Option B. (LMF initiated) LMF determines the DL PRS configuration for training data collection and provides the assistance data to the UE.

Note: the UE can be a PRU and/or a Non-PRU UE.

Note: as in existing specification, the DL PRS configurations in the assistance data from LMF to UE are based on DL PRS configuration coordinated between LMF and gNB..

R1-2407269 Summary #3 of specification support for positioning accuracy enhancement Moderator (Ericsson)

From Wednesday session

Agreement

For the definition of sample-based measurement, select N_t’ samples out of a list of N_t consecutive samples,

· The N_t samples have timing granularity T.

· FFS: the starting time of the list of N_t samples.

· FFS: the value range of N_t

For the sample-based measurement (if accepted in Rel-19),

For measurement by TRP/gNB, the N_t’ selected samples are expected to be those with the highest power.
Note: Choice of the maximum value of Nt, Nt’ should take into account the need to preserve proprietary implementation.

Agreement

For AI/ML positioning Case 2b and 3b, regarding the power information for determining the model input,

· For downlink power measurement, use DL PRS-RSRPP defined in TS 38.215 as a starting point.

o For measurement report of DL PRS-RSRPP, use the existing measurement report mapping table for PRS-RSRPP in 38.133 as a starting point.

· For uplink power measurement, use UL SRS-RSRPP defined in TS 38.215 as a starting point.

o For measurement report of UL SRS-RSRPP, use the existing measurement report mapping table for SRS-RSRPP in 38.133 as a starting point.

Conclusion

From RAN1 perspective, for Case 3a measurements,

· The existing procedures can be reused in terms of SRS configuration.

o Note: parameter values for SRS configuration can be further discussed

· These measurements can be used for multiple aspects related to case 3a, e.g. training data collection, monitoring, or inference procedures.

· Note: Purpose, such as the training data collection, monitoring, or inference procedures mentioned above, will not necessarily be specified in RAN 1 specifications

R1-2407270 Summary #4 of specification support for positioning accuracy enhancement Moderator (Ericsson)

From Thursday session

Agreement

For Rel-19 AI/ML based positioning Case 3b, regarding sample-based measurement (if supported), from RAN1 perspective,

· LMF can signal parameter values of N_t, N_t', k to gNB via NRPPa.

R1-2407271 Summary #5 of specification support for positioning accuracy enhancement Moderator (Ericsson)

Presented in Friday session.

Final summary in R1-2407272.

9.1.3 Additional study on AI/ML for NR air interface

9.1.3.1 CSI prediction

R1-2405900 Discussion on AIML for CSI prediction Spreadtrum Communications, BUPT

R1-2405952 AI/ML based CSI Prediction Google

R1-2405961 Discussion on AI/ML for CSI prediction Tejas Networks Limited

R1-2405977 Discussion on AI/ML for CSI prediction CMCC

R1-2406016 AI/ML for CSI prediction Intel Corporation

R1-2406056 Discussion on study for AI/ML CSI prediction ZTE Corporation, Sanechips

R1-2406068 Discussion on AI/ML for CSI prediction BJTU

R1-2406070 AI/ML for CSI prediction Ericsson

R1-2406174 Discussion on CSI prediction vivo

R1-2406256 Additional study on AI/ML-based CSI prediction OPPO

R1-2406271 Views on UE-side AI/ML model based CSI prediction Xiaomi

R1-2406307 Discussion on CSI prediction with AI/ML Fujitsu

R1-2407183 Further study on AI/ML for CSI prediction CATT (rev of R1-2406355)

R1-2406389 Discussion on AI/ML for CSI prediction China Telecom

R1-2406391 Discussion on AI/ML for CSI prediction Panasonic

R1-2406417 Study on CSI prediction LG Electronics

R1-2406442 On AI/ML for CSI prediction Lenovo

R1-2406465 Discussion on model monitoring of AI/ML CSI Prediction Sony

R1-2406494 Additional study on AI-enabled CSI prediction NVIDIA

R1-2406501 Discussion on AI/ML-based CSI prediction InterDigital, Inc.

R1-2406533 Discussion on CSI prediction NEC

R1-2406588 AI/ML for CSI Prediction Nokia

R1-2406639 Discussion for further study on AI/ML-based CSI prediction Samsung

R1-2406683 Discussion on AI/ML for CSI prediction SK Telecom

R1-2406788 Additional Study on AI/ML - CSI Prediction MediaTek Korea Inc.

R1-2406828 Discussion on AI based CSI prediction Apple

R1-2406870 Discussion on AI/ML for CSI prediction AT&T

R1-2406904 AI/ML for CSI prediction Mavenir

R1-2406922 Discussion on AI/ML for CSI prediction NTT DOCOMO, INC.

R1-2406979 Discussion on CSI prediction for AI/ML Huawei, HiSilicon

R1-2407021 Additional study on CSI prediction Qualcomm Incorporated

R1-2407183 Further study on AI/ML for CSI prediction CATT Late submission

R1-2407338 Summary #1 of CSI prediction Moderator (LG Electronics)

From Tuesday session

Observation

For the generalization verification of CSI prediction using UE sided model over various UE speeds, till the RAN1#118 meeting, compared to the generalization Case 1 where the AI/ML model is trained with dataset subject to a certain UE speed#B and applied for inference with a same UE speed#B,

For generalization Case 2, generalized performance may be achieved for some certain combinations of UE speed#A and UE speed#B but not for others:

If UE speed#B is 10 km/h and

UE speed#A is 30 km/h or 120km/h, 2 sources [Fujitsu, MediaTek] observe a generalized performance of less than -5.5% degradation, and 1 source [LG Electronics] observes -16.2% degradation.
UE speed#A is 60 km/h, 2 sources [CMCC, LG Electronics] observe -26.79%~-13.3% degradation.

If UE speed#B is 30 km/h and

UE speed#A is 60km/h, 4 sources [Huawei, CATT, Ericsson, vivo] observe a generalized performance of -11.4%~-2.7% degradation and 4 sources [CMCC, Nokia, LG Electronics, ZTE] observe a generalized performance of -33.6%~-19% degradation.
UE speed#A is 10km/h or 120km/h, 3 sources [CMCC, MediaTek, Fujitsu] observe a generalized performance of -72.37%~-51.5% degradation.

If UE speed#B is 60 km/h and

UE speed#A is 10km/h, 1 source [LG Electronics] observes a generalized performance of -16.4 degradation
UE speed#A is 30km/h, 1 source [ZTE] observes a generalized performance of -5.4% degradation and 6 sources [Huawei, Fujitsu, MediaTek, Ericsson, vivo, LG Electronics, CATT] observe a generalized performance of -56.3%~-13.8% degradation

If UE speed#B is 120 km/h and

UE speed#A is 30km/h, 1 source [MediaTek] observes a generalized performance of -56.3% degradation

For generalization Case 3, generalized performance of the AI/ML model can be achieved in general (0%~-3.8% loss) for UE speed#B subject to any of 10 km/h, 30 km/h, 60 km/h and 120 km/h, if the training dataset is constructed with data samples subject to multiple UE speeds including UE speed#B, as observed by 8 sources [Fujitsu, Huawei, CATT, vivo, Apple, Ericsson, ZTE, LG Electronics]

If UE speed#B is 10 km/h

2 sources [Fujitsu, MediaTek] observe a generalized performance of less than -0.2% degradation, 1 source [LG Electronics] observe -5.1% degradation, and 1 source [CMCC] observes -16.87% degradation.

If UE speed#B is 30 km/h

9 sources [Huawei, CATT, vivo, Apple, Fujitsu, Ericsson, MediaTek, ZTE, LG Electronics] observe a generalized performance of less than -3.8% degradation, 1 source [CMCC] observes a generalized performance of -15.44% degradation.

If UE speed#B is 60 km/h and

8 sources [Huawei, CATT, vivo, Apple, Fujitsu, Ericsson, ZTE, LG Electronics] observe a generalized performance of less than -3.63% degradation, 3 sources [CMCC, MediaTek] observe a generalized performance of -13.5%~-6.77% degradation.

If UE speed#B is 120 km/h and

1 source [MediaTek] observes a generalized performance of -43.6% degradation

Note: For generalization Case 3, 2 sources [CMCC, MediaTek] observe performance degradations (-43.6%~-13.5% loss) for UE speed#B subject to 10 km/h, 30 km/h, 60 km/h, 120 km/h, but compared with generalization Case 2, in general the performance are still improved.

Note: the above results are based on the following assumptions besides the assumptions of the agreed EVM table

Raw channel matrix is used as the model input.
The performance metric is SGCS in linear value for layer 1/2/3/4.
4 sources [vivo, Ericsson, MediaTek, ZTE] consider spatial consistency. Other sources do not consider spatial consistency.
2 sources [Ericsson, Intel] consider beam-delay domain transformation/antenna-frequency domain transformation as pre/post processing, 1 source [Nokia] considered antenna(port)-delay domain transformation/ antenna(port)-frequency domain transformation as pre/post processing, and other sources do not consider pre/post processing
Note: Results refer to Table 3-1 of R1-2407338

Observation

For the CSI prediction using UE-sided model, till the RAN1#118 meeting, compared to the Benchmark#2 of non-AI based CSI prediction, in terms of SGCS, from perspective of phase discontinuity modelling

If phase discontinuity modelling is not adopted

For 30km/h UE speed,

2 sources [vivo, Fujitsu] observe 4.24%~4.3% gain with N4=1
1 source [vivo] observes 3.1% ~ 40.5% with N4=4
1 source [Qualcomm] observes -1.2%~6.3% with N4=1 depending on filter updates between 10 and 70 learning window size

For 60km/h UE speed,

1 source [vivo] observe 13.5% gain with N4=1, and 1 source [vivo] observe 8.2%~34.6% gain with N4=4
1 source [Qualcomm] observes 0%~8% with N4=1 depending on filter updates between 10 and 70 learning window size

If phase discontinuity modelling is adopted,

For 30km/h UE speed,

Without phase adjustment,

2 sources [vivo, Fujitsu] observe 7.26%~7.8% gain with N4=1
1 source [vivo] observes 6.5%~23.5% gain with N4=4
1 source [Qualcomm] observes -0.8%~8% with N4=1 depending on filter updates between 10 and 70 learning window size

With phase adjustment,

1 source [Qualcomm] observes -1.2%~7.7% gain with N4=1 depending on filter updates between 10 and 70 learning window size
1 source [Fujitsu] observes 25.6% gain

For 60km/h UE speed,

Without phase adjustment,

1 source [vivo] observe 6.6% gain with N4=1 and 6.4%~55% with N4=4
1 source [Qualcomm] observes 5.7%~17.5% gain with N4=1 depending on filter updates between 10 and 70 learning window size

With phase adjustment, 1 source [Qualcomm] observes 4.2%~11.9% gain with N4=1 depending on filter updates between 10 and 70 learning window size

Note: the above results are based on the following assumptions

The observation window considers to start as early as 15ms~50ms.
A future 4ms or 5ms instance from the prediction output is considered for calculating the metric.
Raw channel matrix as model input is assumed.
The performance metric is SGCS in linear value for layer 1.
Note: Results refer to Table 2-12 of R1-2407338

Note: N4 refers to the number of predicted CSI instances

Observation

For the CSI prediction using UE-sided model, till the RAN1#118 meeting, compared to the Benchmark#2 of non-AI based CSI prediction, in terms of SGCS, from channel estimation perspective

If ideal channel estimation is adopted

For N4=1

9 sources [vivo, Nokia, Intel, Fujitsu, InterDigital, Qualcomm, OPPO, Spreadtrum, Lenovo] observe -1.2%~6.3% gain
1 source [Apple] observes -2% ~17% gain depending on filter complexity and filter update

For N4=4

2 sources [OPPO, Intel] observe -1.6%~5.56%
1 source [InterDigital] observes -4.5%~6.93%
1 source [vivo] observes 3.1%~40.5%

If realistic channel estimation is adopted,

For N4=1

5 sources [Intel, Fujitsu, Ericsson, MediaTek, CATT] observe 0.43%~7.26% gain
2 sources [vivo, Nokia] observe 15.2%~19.5 gain
1 source [InterDigital] observes 68% gain
1 source [ZTE] observes 5.8%~16.4% gain depending on traffic load

For N4=4

2 sources [Intel, MediaTek] observe 0.1%~1.4% gain
1 source [Ericsson] observes 5%~29% gain

Note: the above results are based on the following assumptions

The observation window considers to start as early as 15ms~50ms.
A future 4ms or 5ms instance from the prediction output is considered for calculating the metric.
Raw channel matrix as model input and UE speed of 30km/h is assumed.
3 sources [vivo, ZTE, Ericsson] consider spatial consistency, and other sources do not consider spatial consistency.
2 sources [Ericsson, Intel] consider beam-delay domain transformation/antenna-frequency domain transformation as pre/post processing, 1 source [Nokia] considered antenna(port)-delay domain transformation/ antenna(port)-frequency domain transformation as pre/post processing, and other sources do not consider pre/post processing
1 source [Nokia] considers 100% in car UE distribution and other sources consider 100% outdoor UE distribution.
The performance metric is SGCS in linear value for layer 1.

Note: Results refer to Table 2-3 of R1-2407338
Note: N4 refers to the number of predicted CSI instances

Conclusion

For computational complexity of both AI/ML and non-AI/ML based CSI prediction, to report the number of FLOPs assuming whole bandwidth and one prediction sample.

Observation (Update of the observation made in RAN1#117)

For the CSI prediction using UE-sided model, till the RAN1#118 meeting, compared to the Benchmark#1 of the nearest historical CSI, in terms of SGCS, from UE speed perspective,

If spatial consistency is not adopted, and if N4=1

For 10km/h UE speed, 1 source [InterDigital] observes 6% gain
For 30km/h UE speed, 9 sources [Lenovo, Apple, Samsung, China Telecom, Spreadtrum, OPPO, CMCC, Qualcomm, NTT Docomo] observe 5.9%~20.6% gain and 4 sources [Intel, LG Electronics, ZTE, Fujitsu] observe 23.2%~35.4% gain. 2 sources [Nokia, InterDigital] observe 54%~106% gain
For 60km/h UE speed, 4 sources [Qualcomm, China Telecom, Huawei, ZTE] observe 10.5%~26.53% gain

If spatial consistency is adopted, and if N4=1

For 30km/h UE speed, 2 sources [Ericsson, ZTE] observes 22.93%~23% gain, 1 source [vivo] observe 68.5% gain
For 60km/h UE speed, 3 sources [Ericsson, vivo, ZTE] observe 16.2~24.3% gain

If spatial consistency is not adopted, and if N4=4

For 10km/h UE speed, 1 source [LG Electronics] observes 9.1%~29.7% gain
For 30km/h UE speed, 1 source [NTT Docomo] observes 4.3%~12.3% gain, and 2 sources [OPPO, Intel] observe 17.6%~35.4%gain

If spatial consistency is adopted, and if N4=4

For 10km/h UE speed, 1 source [Samsung] observes -1.61%~62.9% gain
For 30km/h UE speed, 1 source [Ericsson] observes 23%~34% gain, 1 source [MediaTek] observe 20.9%~76.4% gain
For 60km/h UE speed, 2 sources [Ericsson, MediaTek] observe 5.96%~-22% gain,

Note: the above results are based on the following assumptions

The observation window considers to start as early as 20ms~50ms.
A future 4ms or 5ms instance from the prediction output is considered for calculating the metric.
7 sources [ZTE, Ericsson, Intel, vivo, Fujitsu, Samsung, MediaTek] consider realistic channel estimation, and other sources consider ideal channel estimation.
1 source [NTT Docomo] considers eigenvector as model input, and other sources considers Raw channel matrix as model input.
1 source [Nokia] considers 100% in car UE distribution and other sources consider 100% outdoor UE distribution.
2 sources [Ericsson, Intel] consider beam-delay domain transformation/antenna-frequency domain transformation as pre/post processing, 1 source [Nokia] considered antenna(port)-delay domain transformation/ antenna(port)-frequency domain transformation as pre/post processing, 1 source [Samsung] considers per layer raw channel matrix after pre-processing, and other sources do not consider pre/post processing.
The performance metric is SGCS in linear value for layer 1.

Note: N4 refers to the number of predicted CSI instances

Note: Results refer to Table 2-1 of R1-2407338

Observation (Update of the observation made in RAN1#117)

For the CSI prediction using UE-sided model, till the RAN1#118 meeting, in terms of mean UPT, gains are observed compared to Benchmark#1 of the nearest historical CSI:

For FTP traffic with low RU (RU<=39%)

For 30km/h UE speed and N4=1

2 sources [Intel, NTT Docomo] observe -0.2%~1% gain
4 sources [Ericsson, Fujitsu, Apple, Nokia] observe 4.4%~9% gain.

For 60km/h UE speed, and N4=1

2 sources [Huawei, Ericsson] observe 1.2%~5% gain;

For 30km/h UE speed and N4=4

1 source [NTT Docomo] observes 0.3% gain.
1 source [Ericsson] observes 7% gain.

For 60km/h UE speed, and N4=4

1 source [Ericsson] observes 5% gain.

For FTP traffic with mid RU (40<=RU<=69%)

For 30km/h UE speed and N4=1

2 sources [Intel, NTT Docomo] observe 0.9%~2.3% gain
1 source [Apple] observe 8.5% gain
2 sources [Ericsson, Fujitsu] observe 22.3%~37% gain.

For 60km/h UE speed, and N4=1

1 source [Huawei] observe 1.8%~3.5% gain;
1 source [Ericsson] observes 21% gain.

For 30km/h UE speed and N4=4

1 source [NTT Docomo] observes 2.3% gain.
1 source [Ericsson] observes 29% gain.

For 60km/h UE speed, and N4=4

1 source [Ericsson] observes 21% gain.

For FTP traffic with high RU (RU>=70%)

For 30km/h UE speed and N4=1

4 sources [Intel, NTT Docomo, OPPO] observe 2%~3.6% gain
2 sources [Fujitsu, Apple] observe 8.5%~31.7% gain.

For 30km/h UE speed and N4=4

1 source [NTT Docomo] observes 7.2% gain.

For 60km/h UE speed, and N4=1

1 source [Huawei] observes 4.2% gain;

For full buffer traffic:

For 30km/h UE speed and N4=1

3 sources [Lenovo, Fujitsu, vivo] observe 27%~51% gain.
2 sources [MediaTek, Intel] observe 1.2%~8.7% gain.

For 60km/h UE speed and N4=1

1 source [vivo] observe 12.1% gain.

For 30km/h UE speed and N4=4

1 source [Fujitsu] observes 11.6% gain.

Note: the above results are based on the following assumptions

The observation window considers to start as early as 15ms~50ms.
A future 4ms ~ 20ms instance from the prediction output is considered for calculating the metric.
Raw channel matrix is considered as model input
~~The performance metric is mean UPT for Max rank 1.~~
2 sources [Ericsson, Intel] consider beam-delay domain transformation/antenna-frequency domain transformation as pre/post processing, 1 source [Nokia] considered antenna(port)-delay domain transformation/ antenna(port)-frequency domain transformation as pre/post processing, and other sources do not consider pre/post processing
3 sources [vivo, Ericsson, MediaTek] consider spatial consistency, and other sources do not consider spatial consistency.
1 source [Nokia] considers 100% in car UE distribution and other sources consider 100% outdoor UE distribution.
5 sources [Ericsson, Fujitsu, CATT, MediaTek, vivo] consider realistic channel estimation, and other sources consider ideal channel estimation.
1 source [vivo] are modelled phase discontinuity, and other sources do not consider phase discontinuity

Note: N4 refers to the number of predicted CSI instances
Note: Results refer to Table 2-5/2-7 of R1-2407338

Observation (Update of the observation made in RAN1#117)

For the CSI prediction using UE-sided model, till the RAN1#118 meeting, in terms of 5% UE UPT, gains are observed compared to Benchmark#1 of the nearest historical CSI:

For FTP traffic with low RU (RU<=39%)

For 30km/h UE speed and N4=1

1 source [NTT Docomo] observes 1.5% gain.
4 sources [Intel, Fujitsu, Apple, Nokia] observe 6.7%~15.7% gain.
1 source [Ericsson] observes 27% gain.

For 60km/h UE speed, and N4=1

2 sources [Huawei, Ericsson] observe 9%~18.3% gain;

For 30km/h UE speed and N4=4

1 source [NTT Docomo] observes 3.6% gain.
1 source [Ericsson] observes 14% gain.

For 60km/h UE speed, and N4=4

1 source [Ericsson] observes 4% gain.

For FTP traffic with mid RU (40<=RU<=69%)

For 30km/h UE speed and N4=1

1 source [NTT Docomo] observes 4.1% gain.
2 sources [Intel, Fujitsu, Apple] observe 14.3%~38.9% gain.
1 source [Ericsson] observes 100% gain.

For 60km/h UE speed, and N4=1

1 source [Huawei] observes 11.3% gain;
1 source [Ericsson] observes 45% gain.

For 30km/h UE speed and N4=4

1 source [NTT Docomo] observes 10% gain.
1 source [Ericsson] observes 77% gain.

For 60km/h UE speed, and N4=4

1 source [Ericsson] observes 26% gain.

For FTP traffic with high RU (RU>=70%)

For 30km/h UE speed, and N4=1

1 source [Fujitsu] observes 51.7% gain.
3 sources [Intel, NTT Docomo, Apple] observe 7.8%~15.8% gain

For 60km/h UE speed, and N4=1

1 source [Huawei] observe 17.8% gain;

For 30km/h UE speed, and N4=4

1 source [NTT Docomo] observes 6.2% gain

For full buffer traffic:

For 30km/h UE speed and N4=1

4 sources [Fujitsu, MediaTek, Lenovo, Intel] observe 7.7%~10.5% gain.
1 source [vivo] observes 39.7% gain.

For 60km/h UE speed and N4=1

1 source [vivo] observes 20.6% gain.

For 30km/h UE speed and N4=4

1 source [Fujitsu] observes 2.1% gain.

Note: the above results are based on the following assumptions

The observation window considers to start as early as 15ms~50ms.
A future 4ms ~ 20ms instance from the prediction output is considered for calculating the metric.
Raw channel matrix is considered as model input
~~The performance metric is mean UPT for Max rank 1.~~
2 sources [Ericsson, Intel] consider beam-delay domain transformation/antenna-frequency domain transformation as pre/post processing, 1 source [Nokia] considered antenna(port)-delay domain transformation/ antenna(port)-frequency domain transformation as pre/post processing, and other sources do not consider pre/post processing
3 sources [vivo, Ericsson, MediaTek] consider spatial consistency, and other sources do not consider spatial consistency.
1 source [Nokia] considers 100% in car UE distribution and other sources consider 100% outdoor UE distribution.
5 sources [Ericsson, Fujitsu, CATT, MediaTek, vivo] consider realistic channel estimation, and other sources consider ideal channel estimation.
1 source [vivo] are modelled phase discontinuity, and other sources do not consider phase discontinuity

Note: N4 refers to the number of predicted CSI instances
Note: Results refer to Table 2-5/2-7 of R1-2407338

R1-2407339 Summary #2 of CSI prediction Moderator (LG Electronics)

From Wednesday session

Observation

For the CSI prediction using UE-sided model, till the RAN1#118 meeting, compared to the Benchmark#2 of non-AI based CSI prediction, in terms of SGCS, from UE speed perspective

If spatial consistency is not adopted, if N4=1

For 10km/h UE speed, 1 source [InterDigital] observes 0% gain
For 30km/h UE speed,

7 sources [Lenovo, Spreadtrum, Intel, CATT, Fujitsu, ZTE, Nokia] observe 1%~19.5% gain,
1 source [InterDigital] observes 68% gain
2 sources [Apple, Qualcomm] observe -2% ~17% gain depending on filter complexity and filter update

For 60km/h UE speed,

3 sources [Huawei, CATT, ~~Qualcomm,~~ ZTE] observe 3.6%~26.35% gain,
1 source [InterDigital] observes 35% gain
1 source [Qualcomm] observe 0% ~8.7% gain depending on filter complexity and filter update

If spatial consistency is adopted, if N4=1

For 30km/h UE speed,

1 source [Ericsson] observes 5% gain,
2 sources [vivo, ZTE] observe 15.2%~16.4%

For 60km/h UE speed,

3 sources [Ericsson, vivo, ZTE] observes 3%~13.5% gain,

If spatial consistency is not adopted, if N4=4

For 10km/h UE speed, 1 source [InterDigital] observes 0%~1.4% gain
For 30km/h UE speed, 3 sources [InterDigital, Intel, OPPO] observe -1.6%~6.93% gain,
For 60km/h UE speed, 1 source [InterDigital] observes -4%~7.3% gain

If spatial consistency is adopted, if N4=4

For 30km/h UE speed,

1 source [MediaTek] observes 0.43%~0.97% gain
1 source [Ericsson] observes 5%~29% gain
1 source [vivo] observes 28.9%~43.6% gain

For 60km/h UE speed,

1 source [MediaTek] observes -1.01%~1.52% gain
1 source [Ericsson] observes 3%~16% gain
1 source [vivo] observes 10.0%~32.3% gain

Note: the above results are based on the following assumptions

The observation window considers to start as early as 15ms~50ms.
A future 4ms or 5ms instance from the prediction output is considered for calculating the metric.
6 sources [ZTE, Ericsson, Intel, vivo, Fujitsu, CATT] consider realistic channel estimation, and other sources consider ideal channel estimation.
All sources consider Raw channel matrix as model input.
1 source [Nokia] considers 100% in car UE distribution and other sources consider 100% outdoor UE distribution.
2 sources [Ericsson, Intel] consider beam-delay domain transformation/antenna-frequency domain transformation as pre/post processing, 1 source [Nokia] considered antenna(port)-delay domain transformation/ antenna(port)-frequency domain transformation as pre/post processing, and other sources do not consider pre/post processing
The performance metric is SGCS in linear value for layer 1.

Note: N4 refers to the number of predicted CSI
Note: Results refer to Table 2-3 of R1-2407339

Observation

For the CSI prediction using UE-sided model, till the RAN1#118 meeting, in terms of mean UPT, gains are observed compared to Benchmark#2 of a non-AI/ML based CSI prediction approach:

For FTP traffic, with low RU (RU<=39%)

For 30km/h UE speed and N4=1,

2 sources [Ericsson, InterDigital] observe 7.6%~9% gain.
4 sources [CATT, Intel, Fujitsu, Nokia] observe -2.41%~1.1% gain.

For 60km/h UE speed, and N4=1

1 source [InterDigital] observe -3.4% gain
2 sources [Huawei, CATT] observes 0.9%~1.2% gain;
1 source [Ericsson] observes 11% gain.

For 30km/h UE speed and N4=4,

1 source [Ericsson] observes 13% gain.
2 sources [InterDigital, MediaTek] observe 0%~0.3% gain.

For 60km/h UE speed, and N4=4

1 source [Ericsson,] observes 13%
1 source [MediaTek] observes 0.14% gain

For FTP traffic, with mid RU (40<=RU<=69%)

For 30km/h UE speed and N4=1,

1 source [Ericsson] observes 24% gain.
3 sources [InterDigital, Intel, Fujitsu] observe 0.2%~5.1% gain.

For 60km/h UE speed, and N4=1

1 source [InterDigital] observes -29.4% gain;
1 source [Huawei] observes 3.1% gain;
1 source [Ericsson] observes 31% gain.

For 30km/h UE speed and N4=4,

1 source [Ericsson] observes 35% gain.
2 sources [MediaTek, InterDigital] observe -0.25%~2% gain.

For 60km/h UE speed, and N4=4

1 source [InterDigital] observes -16.2% gain.
1 source [MediaTek] observes 0.25% gain.
1 source [Ericsson] observes 32% gain.

For FTP traffic, with high RU (RU>=70%)

For 30km/h UE speed, and N4=1

4 sources [InterDigital, Intel, Fujitsu, OPPO] observes -0.2%~9.2% gain;

For 60km/h UE speed, and N4=1

1 source [Huawei] observes 2.5% gain;

For 30km/h UE speed and N4=4,

2 sources [InterDigital, MediaTek] observes -0.8%~0.11% gain.

For 60km/h UE speed, and N4=4

1 source [InterDigital] observes -19.1% gain.
1 source [MediaTek] observes 0.92% gain.

For full buffer traffic:

For 30km/h UE speed and N4=1

2 sources [Lenovo, ZTE] observe 10.6%~24% gain.
2 sources [Fujitsu, vivo] observe 7.8%~9.7% gain.
3 sources [CATT, MediaTek, Intel] observe -0.6%~1.2% gain.

For 60km/h UE speed, and N4=1

1 source [CATT] observes 0.2% gain
1 source [vivo] observes 8.4% gain

For 30km/h UE speed and N4= 4

1 source [Fujitsu] observes 7% gain.
1 source [vivo] observes 6.8% gain

For 60km/h UE speed and N4=4

1 source [vivo] observes 11.6% gain

Note: the above results are based on the following assumptions

The observation window considers to start as early as 15ms~50ms.
A future 4ms ~ 20ms instance from the prediction output is considered for calculating the metric.
Raw channel matrix is considered as model input
2 sources [Ericsson, Intel] consider beam-delay domain transformation/antenna-frequency domain transformation as pre/post processing, 1 source [Nokia] considered antenna(port)-delay domain transformation/ antenna(port)-frequency domain transformation as pre/post processing, and other sources considers no pre/post processing.
3 sources [vivo, Ericsson, MediaTek] consider spatial consistency, and other sources do not consider spatial consistency.
1 source [Nokia] considers 100% in car UE distribution and other sources consider 100% outdoor UE distribution.
5 sources [Ericsson, Fujitsu, CATT, MediaTek, vivo] consider realistic channel estimation, and other sources consider ideal channel estimation.
1 source [vivo] are modelled phase discontinuity, and other sources do not consider phase discontinuity

Note: N4 refers to the number of predicted CSI instances
Note: Results refer to Table 2-6/2-8 of R1-247339
Note: The following boxchart shows the median, 0.75 quantile, 0.25 quantile, outliers, and min/max values excluding outliers, for low RU, Mid RU, High RU and full buffer with UE speed of 30km/h.

Observation

For the CSI prediction using UE-sided model, till the RAN1#118 meeting, in terms of 5% UE UPT, gains are observed compared to Benchmark#2 of a non-AI/ML based CSI prediction approach:

For FTP traffic, with low RU (RU<=39%)

For 30km/h UE speed and N4=1,

2 sources [Ericsson, InterDigital] observe 18%~26% gain.
4 sources [CATT, Fujitsu, Intel, Nokia] observe -1.1%~7.6% gain.

For 60km/h UE speed, and N4=1

3 sources [Huawei, InterDigital, CATT] observe 1.9%~5.2% gain;
1 source [Ericsson] observes 17% gain.

For 30km/h UE speed and N4=4,

1 source [Ericsson] observes 23% gain.
1 source [InterDigital] observes -3.7% gain.

For 60km/h UE speed, and N4=4

1 source [Ericsson] observe 19%gain.
1 source [InterDigital] observes 4%gain.

For FTP traffic, with mid RU (40<=RU<=69%)

For 30km/h UE speed and N4=1,

1 source [Ericsson] observes 46% gain.
1 source [InterDigital] observes 18.7% gain.
2 sources [Intel, Fujitsu] observe 4%~6.6% gain.

For 60km/h UE speed, and N4=1

1 source [Huawei] observes 8.6% gain;
2 sources [Ericsson, InterDigital] observe 23%~66% gain.

For 30km/h UE speed and N4=4,

1 source [Ericsson] observes 73% gain.
1 source [InterDigital] observes -9% gain.

For 60km/h UE speed, and N4=4

1 source [Ericsson] observes 56% gain.
1 source [InterDigital] observes 11.5% gain.

For FTP traffic, with high RU (RU>=70%)

For 30km/h UE speed, and N4=1

1 source [Intel] observes 1.9% gain;
2 sources [InterDigital, Fujitsu] observe 20.7%~26.3% gain;

For 60km/h UE speed, and N4=1

1 source [Huawei, InterDigital] observes 14.8%~16% gain;

For 30km/h UE speed and N4=4,

1 source [InterDigital] observes 0.9% gain.

For 60km/h UE speed, and N4=4

1 source [InterDigital] observes 22.8% gain.

For full buffer traffic:

For 30km/h UE speed and N4=1

2 sources [vivo, ZTE] observe 15.7%~16.1% gain.
4 sources [Lenovo, Fujitsu, CATT, Intel] observe 0.2%~6% gain.
1 source [MediaTek] observes -2% gain.

For 60km/h UE speed, and N4=1

1 source [CATT] observes 0.4% gain
1 source [vivo] observes 11.6% gain

For 30km/h UE speed and N4= 4

1 source [Fujitsu] observes 6.3% gain.
1 source [vivo] observes 21% gain

For 60km/h UE speed and N4=4
1 source [vivo] observes 26.7% gain

Note: the above results are based on the following assumptions

The observation window considers to start as early as 15ms~50ms.
A future 4ms ~ 20ms instance from the prediction output is considered for calculating the metric.
Raw channel matrix is considered as model input
2 sources [Ericsson, Intel] consider beam-delay domain transformation/antenna-frequency domain transformation as pre/post processing, 1 source [Nokia] considered antenna(port)-delay domain transformation/ antenna(port)-frequency domain transformation as pre/post processing, and other sources considers no pre/post processing.
3 sources [vivo, Ericsson, MediaTek] consider spatial consistency, and other sources do not consider spatial consistency.
1 source [Nokia] considers 100% in car UE distribution and other sources consider 100% outdoor UE distribution.
5 sources [Ericsson, Fujitsu, CATT, MediaTek, vivo] consider realistic channel estimation, and other sources consider ideal channel estimation.
1 source [vivo] are modelled phase discontinuity, and other sources do not consider phase discontinuity

Note: N4 refers to the number of predicted CSI instances
Note: Results refer to Table 2-6/2-8 of R1-2407339
Note: The following boxchart shows the median, 0.75 quantile, 0.25 quantile, outliers, and min/max values excluding outliers, for low RU, Mid RU, High RU and full buffer with UE speed of 30km/h.

Observation

· From a perspective of AI/ML complexity, 19 sources adopt the model subject to the computational complexity in units of FLOPs from 0.05M to 3000M. The actual model complexity may differ from the model complexity in the evaluation with respect to platform-dependent optimization on model implementations.

· From a perspective of complexity of non-AI/ML benchmark, 16 sources adopt the algorithm (e.g., Kalman filter, Auto-regression, Wiener filter) subject to the computational complexity in units of FLOPs from 0.14M to 107M. For non-AI/ML benchmark, main computation complexity is dominated by filter updates, which may not be need to be updated per inference at the expense of performance loss. For example, 7 sources adopt the algorithm subject to the computational complexity of filter updates and inference in units of FLOPs from 0.47M to 106M and 0.067M to 3M, respectively.

· Results refer to Figure 2-1, Table 2-9, and Table 2-10 in R1-2407339.

Observation

For the generalization verification of CSI prediction using UE sided model over various deployment scenarios, till the RAN1#118 meeting, compared to the generalization Case 1 where the AI/ML model is trained with dataset subject to a certain deployment scenario#B applied for inference with a same deployment scenario#B

· For generalization Case 2, generalized performance may be achieved for some certain combinations of deployment scenario#A and deployment scenario#B but not for others:

o For deployment scenario#B is Uma

§ 2 sources [Ericsson, MediaTek] observe -1.88%~0% degradation

§ 1 source [MediaTek] observe -6.8% degradation

o For deployment scenario#B is UMi

§ 1 source [MediaTek] observe 0% degradation

§ 3 sources [Ericsson, vivo, ZTE] observe -4.85%~-3.03% degradation

· For generalization Case 3, generalized performance of the AI/ML model can be achieved (-1.95%~0% loss) for deployment scenario#B subject to any of UMa and UMi, if the training dataset is constructed with data samples subject to multiple deployment scenarios including deployment scenario#B as observed by 3 sources.

o Minor loss (0%~-1.95%) are observed by 3 sources [vivo, ZTE, MediaTek].

o Note: Moderate degradations of -5.2% are observed by 1 source [vivo] for deployment scenario#B subject to Uma

· Note: the above results are based on the following assumptions besides the assumptions of the agreed EVM table

o Raw channel matrix is used as the model input.

o The performance metric is SGCS in linear value for layer 1/2/3/4.

o 3 sources [vivo, Ericsson, MediaTek] consider spatial consistency. Other sources do not consider spatial consistency.

o 1 source [Ericsson] considers beam-delay domain transformation/antenna-frequency domain transformation as pre/post processing, and other sources considers no pre/post processing.

o Note: Results refer to Table 3-2 of R1-2407339

Observation

For the generalization verification of CSI prediction using UE sided model over various carrier frequency, till the RAN1#118 meeting, compared to the generalization Case 1 where the AI/ML model is trained with dataset subject to a certain carrier frequency#B applied for inference with a same carrier frequency#B

· For generalization Case 2, significant degradations are suffered in general from the perspective of the layouts of antenna ports, as observed by 3 sources:

o For carrier frequency#B is 2GHz

§ 1 source [MediaTek] observe -11.4% degradation

§ 1 source [vivo] observe -80.53% degradation

o For carrier frequency#B is 3GHz or 4GHz

§ 2 sources [MediaTek, vivo] observe -34.23%~-80.53% degradation

§ 1 source [ZTE] observe -4.21% degradation

· For generalization Case 3, generalized performance may be achieved for some certain combinations of carrier frequency#A and carrier frequency#B but not for others, if the training dataset is constructed with data samples subject to multiple carrier frequencies including carrier frequency#B

o For carrier frequency#B is 2GHz

§ 1 source [MediaTek] observe -0.5% degradation

§ 1 source [vivo] observe -9.27% degradation

o For carrier frequency#B is 3GHz or 4GHz

§ 2 sources [MediaTek, ZTE] observe -1.93%~-5.1% degradation

§ 1 source [vivo] observe -14.94% degradation

· Note: the above results are based on the following assumptions besides the assumptions of the agreed EVM table

o Raw channel matrix is used as the model input.

o The performance metric is SGCS in linear value for layer 1/2/3/4.

o 2 sources [vivo, MediaTek] consider spatial consistency. Other sources do not consider spatial consistency.

o Note: Results refer to Table 3-3 of R1-2407339

Observation

For the generalization verification of CSI prediction using UE sided model over multiple aspects, till the RAN1#118 meeting, compared to the generalization Case 1 where the AI/ML model is trained with dataset subject to certain aspects #B applied for inference with the same aspects #B,

· For generalization Case 2,

o 1 source [NTT DOCOMO] observes -9.8% ~ -1.5% degradation when the aspects #A is (2 GHz carrier frequency, 100% outdoor UE) and the aspects #B is (4GHz carrier frequency, 20% outdoor UE+80% indoor UE)

o 1 source [NTT DOCOMO] observes -10.7%~-1.8% when the aspects#A is (UMa, 2 GHz carrier frequency, 100% outdoor UE distribution) and the aspects#B is (UMi, 4 GHz carrier frequency, 100 outdoor UE)

o 1 source [NTT DOCOMO] observes -21.2%~-2.4% when the aspects#A is (UMa, 2 GHz carrier frequency, 100% outdoor UE distribution) and the aspects#B is (UMi, 4 GHz carrier frequency, 20% outdoor UE+80% indoor UE distribution)

o 1 source [Nokia] observe -3% degradation when aspects#A is (30km/h UE speed, 100% UE in a car, 2GHz carrier frequency) and the aspects#B is (3km/h UE speed, 20% outdoor UE, 4GHz carrier frequency)

· For generalization Case 3,

o 1 source [NTT DOCOMO] observes -1.1%~0% when the aspects#A is (2 GHz carrier frequency, 100% outdoor UE distribution) and the aspects #B is (4GHz carrier frequency, 20% outdoor UE+80% indoor UE distribution)

o 1 source [NTT DOCOMO] observes -2.4%~-0.8% when the aspects#A is (UMa, 2 GHz carrier frequency, 100% outdoor UE distribution) and the aspects#B is (UMi, 4 GHz carrier frequency, 100 outdoor UE)

o 1 source [NTT DOCOMO] observes -3.4%~-0.3% when the aspects#A is (UMa, 2 GHz carrier frequency, 100% outdoor UE distribution) and the aspects#B is (UMi, 4 GHz carrier frequency, 20% outdoor UE+80% indoor UE distribution)

· Note: the above results are based on the following assumptions besides the assumptions of the agreed EVM table

o The performance metric is SGCS in linear value for layer 1/2/3/4.

o 1 source [NTT Docomo] considers eigenvector as model input, and 1 source [Nokia]s considers Raw channel matrix as model input.

o Note: Results refer to Table 3-4 of R1-2407339

Observation

For the CSI prediction using CSI-RS with 20ms periodicity, till the RAN1#118 meeting, in terms of mean and 5% UE UPT, gains are observed compared to Benchmark #1 of the nearest historical CSI and Benchmark #2 of non-AI/ML based CSI prediction,

Compared to Benchmark 1

In terms of UPT gain

For N4=1 and UE speed of 3km/h, 1 source [Ericsson] observes -18%~-7% and -26%~-8% degradation in terms of mean and 5% UE UPT, respectively.
For N4=4 and UE speed of 3km/h, 1 source [Ericsson] observes 1%~6% and 6%~17% gain in terms of mean and 5% UE UPT, respectively.
For N4=4 and UE speed of 30km/h, 1 source [Ericsson] observes 2%~17% and 13%~19% gain in terms of mean and 5% UE UPT, respectively, by using one 20ms periodic CSI-RS and three aperiodic CSI-RS.

Compared to Benchmark 2

For N4=1 and UE speed of 3km/h,

1 source [Ericsson] observes 10%~19% and 23%~31% gain in terms of mean and 5% UE UPT, respectively.
1 source [InterDigital] observes -2.7%~-1% and -10.4%~-4.9% degradation in terms of mean and 5% UE UPT, respectively.

For N4=1 and UE speed of 10km/h, 1 source [InterDigital] observes 0.6%~1% gain and -14.2%~-8% gain in terms of mean and 5% UE UPT, respectively.
For N4=4 and UE speed of 3km/h, 1 source [Ericsson] observes 14%~30% and 19%~56% gain in terms of mean and 5% UE UPT, respectively.
For N4=4 and UE speed of 30km/h,

1 source [ZTE] observes 17.3% and 16.1 gain in terms of mean and 5% UE UPT, receptively.
1 source [Ericsson] observes 5%~19% and 13%~40% gain in terms of mean and 5% UE UPT, respectively, by using one 20ms periodic CSI-RS and three aperiodic CSI-RS.

Note: the above results are based on the following assumptions besides the assumptions of the agreed EVM table

1 source [ZTE] considers full buffer model, other sources consider FTP traffic model
Raw channel matrix is used as the model input.
5 sources [Ericsson, ZTE] consider realistic channel estimation, and other sources consider ideal channel estimation.
The performance metric is SGCS in linear value for layer 1/2/3/4 and mean UPT, 5% UPT.
2 sources [Ericsson] consider spatial consistency. Other sources do not consider spatial consistency.
Note: Results refer to Tables 2-13, 2-14, 2-15, 2-16 of R1-2407339

R1-2407340 Summary #3 of CSI prediction Moderator (LG Electronics)

From Thursday session

Observation

For the CSI prediction using UE-sided model, till the RAN1#118 meeting, in terms of mean UPT, gains are observed compared to Benchmark#2 of a non-AI/ML based CSI prediction, from channel estimation perspective:

For FTP traffic, with low RU (RU<=39%)

With ideal channel estimation

§ For 30km/h UE speed and N4=1,

· 2 sources [Nokia, InterDigital] observe -2.41%~1.8% gain.

§ For 60km/h UE speed, and N4=1

· 2 sources [InterDigital, Huawei] observe -3.4%~0.9% gain

§ For 30km/h UE speed and N4=4,

· 1 source [InterDigital] observes 0.3% gain.

o With realistic channel estimation

§ For 30km/h UE speed and N4=1,

· 2 sources [Ericsson, InterDigital] observe 7.6%~9% gain.

· 3 sources [CATT, Intel, Fujitsu] observe 0%~1.1% gain.

§ For 60km/h UE speed, and N4=1

· 2 sources [InterDigital, CATT] observe -3.4%~1.2% gain

· 1 source [Ericsson] observes 11% gain.

§ For 30km/h UE speed and N4=4,

· 1 source [Ericsson] observes 13% gain.

· 1 source [MediaTek] observes 0% gain.

§ For 60km/h UE speed, and N4=4

· 1 source [Ericsson] observes 13%

· 1 source [MediaTek] observes 0.14% gain

· For FTP traffic, with mid RU (40<=RU<=69%)

With ideal channel estimation

§ For 30km/h UE speed and N4=1,

· 1 source [InterDigital] observes -4.5% gain.

§ For 60km/h UE speed, and N4=1

· 1 source [InterDigital] observes -7.1% gain

· 1 source [Huaweil] observes 3.1% gain

§ For 30km/h UE speed and N4=4,

· 1 source [InterDigital] observes -2% gain.

o With realistic channel estimation

§ For 30km/h UE speed and N4=1,

· 2 sources [Ericsson] observe 24% gain.

· 3 sources [InterDigital, Intel, Fujitsu] observe 0.2%~5.1% gain.

§ For 60km/h UE speed, and N4=1

· 1 source [Ericsson] observes 31% gain

· 1 source [InterDigital] observes -29.4% gain

§ For 30km/h UE speed and N4=4,

· 1 source [Ericsson] observes 35% gain.

· 2 sources [MediaTek, InterDigital] observe -0.25%~1.1% gain

§ For 60km/h UE speed, and N4=4

· 1 source [Ericsson] observes 32%

· 1 source [MediaTek] observes 0.25% gain

· For FTP traffic, with high RU (RU>=70%)

With ideal channel estimation

§ For 30km/h UE speed and N4=1,

· 1 source [InterDigital] observes -4.8% gain

§ For 60km/h UE speed, and N4=1

· 1 source [InterDigital] observes -9% gain

· 1 source [Huaweil] observes 2.5% gain

§ For 30km/h UE speed and N4=4,

· 1 source [InterDigital] observes -0.8% gain.

o With realistic channel estimation

§ For 30km/h UE speed and N4=1,

· 3 sources [InterDigital, Intel, OPPO] observe 0%~0.8%

· 1 source [Fujitsu] observes 9.2% gain.

§ For 60km/h UE speed, and N4=1

· 1 source [InterDigital] observes -9% gain

§ For 30km/h UE speed and N4=4,

· 2 sources [MediaTek, InterDigital] observe 0%~0.1% gain

§ For 60km/h UE speed, and N4=4

· 1 source [MediaTek] observes 0.92% gain

· For full buffer model,

With ideal channel estimation

§ For 30km/h UE speed and N4=1,

· 1 source [Lenovo] observes 24%

o With realistic channel estimation

§ For 30km/h UE speed and N4=1

· 3 sources [Fujitsu, vivo, ZTE] observe 7.8%~10.6% gain.

· 3 sources [CATT, MediaTek, Intel] observe -0.6%~1.2% gain.

§ For 60km/h UE speed, and N4=1

· 1 source [CATT] observes 0.2% gain

· 1 source [vivo] observes 8.4% gain

§ For 30km/h UE speed and N4= 4

· 1 source [Fujitsu] observes 7% gain.

· 1 source [vivo] observes 6.8% gain

§ For 60km/h UE speed and N4=4

· 1 source [vivo] observes 11.6% gain

· Note: the above results are based on the following assumptions

o The observation window considers to start as early as 15ms~50ms.

o A future 4ms ~ 20ms instance from the prediction output is considered for calculating the metric.

o Raw channel matrix is considered as model input

o 2 sources [Ericsson, Intel] consider beam-delay domain transformation/antenna-frequency domain transformation as pre/post processing, 1 source [Nokia] considered antenna(port)-delay domain transformation/ antenna(port)-frequency domain transformation as pre/post processing, and other sources considers no pre/post processing.

o 3 sources [vivo, Ericsson, MediaTek] consider spatial consistency, and other sources do not consider spatial consistency.

o 1 source [Nokia] considers 100% in car UE distribution and other sources consider 100% outdoor UE distribution.

· Note: N4 refers to the number of predicted CSI instances

· Note: Results refer to Table 2-6/2-8 of R1-2407340

Observation

For the CSI prediction using UE-sided model, till the RAN1#118 meeting, in terms of 5% UE UPT, gains are observed compared to Benchmark#2 of a non-AI/ML based CSI prediction, from channel estimation perspective:

For FTP traffic, with low RU (RU<=39%)

With ideal channel estimation

§ For 30km/h UE speed and N4=1,

· 1 source [InterDigital] observe -5.5% gain.

§ For 60km/h UE speed, and N4=1

· 2 sources [InterDigital, Huawei] observe 4%~4.3% gain

§ For 30km/h UE speed and N4=4,

· 1 source [InterDigital] observes -3.7% gain.

o With realistic channel estimation

§ For 30km/h UE speed and N4=1,

· 2 sources [Ericsson] observe 17% gain.

· 2 sources [CATT, InterDigital] observe 0%~4% gain.

§ For 60km/h UE speed, and N4=1

· 1 source [CATT] observes 1.9% gain

· 1 source [Ericsson] observes 17% gain.

§ For 30km/h UE speed and N4=4,

· 1 source [Ericsson] observes 23% gain.

§ For 60km/h UE speed, and N4=4

· 1 source [Ericsson] observes 19%

· For FTP traffic, with mid RU (40<=RU<=69%)

With ideal channel estimation

§ For 30km/h UE speed and N4=1,

· 1 source [InterDigital] observes -12.9% gain.

§ For 60km/h UE speed, and N4=1

· 1 source [InterDigital] observes 2.6% gain

· 1 source [Huaweil] observes 8.6% gain

§ For 30km/h UE speed and N4=4,

· 1 source [InterDigital] observes -9% gain.

o With realistic channel estimation

§ For 30km/h UE speed and N4=1,

· 2 sources [Intel, Fujitsu] observe 4%~6.6% gain.

· 1 source [InterDigital] observes 18.7% gain.

· 1 source [Ericsson] observes 46% gain.

§ For 60km/h UE speed, and N4=1

· 1 source [Ericsson] observes 66% gain

· 1 source [InterDigital] observes 2.6% gain

§ For 30km/h UE speed and N4=4,

· 1 source [Ericsson] observes 73% gain.

· 1 source [InterDigital] observes 18.7% gain

§ For 60km/h UE speed, and N4=4

· 1 source [Ericsson] observes 56%

· For FTP traffic, with high RU (RU>=70%)

With ideal channel estimation

§ For 30km/h UE speed and N4=1,

· 1 source [InterDigital] observes 3.6% gain

§ For 60km/h UE speed, and N4=1

· 1 source [InterDigital] observes -10.7% gain

· 1 source [Huaweil] observes 14.8% gain

§ For 30km/h UE speed and N4=4,

· 1 source [InterDigital] observes 0.9% gain.

o With realistic channel estimation

§ For 30km/h UE speed and N4=1,

· 2 sources [InterDigital, Fujitsu] observes 20.7%~26.3%

· 1 source [Intel] observes 1.9% gain.

§ For 60km/h UE speed, and N4=1

· 1 source [InterDigital] observes 3.6% gain

§ For 30km/h UE speed and N4=4,

· 1 source [InterDigital] observes 0.9% gain

· For full buffer model,

With ideal channel estimation

§ For 30km/h UE speed and N4=1,

· 1 source [Lenovo] observes 0.2%

o With realistic channel estimation

§ For 30km/h UE speed and N4=1

· 2 sources [vivo, ZTE] observe 15.7%~16.1% gain.

· 3 sources [Fujitsu, CATT, Intel] observe 2.6%~7.7% gain.

· 1 source [MediaTek] observes -2% gain.

§ For 60km/h UE speed, and N4=1

· 1 source [CATT] observes 0.4% gain

· 1 source [vivo] observes 11.6% gain

§ For 30km/h UE speed and N4= 4

· 1 source [Fujitsu] observes 6.3% gain.

· 1 source [vivo] observes 21% gain

§ For 60km/h UE speed and N4=4

· 1 source [vivo] observes 26.7% gain

· Note: the above results are based on the following assumptions

o The observation window considers to start as early as 15ms~50ms.

o A future 4ms ~ 20ms instance from the prediction output is considered for calculating the metric.

o Raw channel matrix is considered as model input

o 3 sources [vivo, Ericsson, MediaTek] consider spatial consistency, and other sources do not consider spatial consistency.

o 1 source [Nokia] considers 100% in car UE distribution and other sources consider 100% outdoor UE distribution.

· Note: N4 refers to the number of predicted CSI instances

· Note: Results refer to Table 2-6/2-8 of R1-2407340

Observation

The following aspects have been studied for CSI prediction using UE-sided model:

· From the perspective of basic performance gain over non-AI/ML benchmark (without considering generalization),

o It has been studied with corresponding observations on:

§ the metrics of SGCS, mean UPT, 5% UPT;

§ the benchmarks of nearest historical CSI and non-AI/ML based CSI prediction.

§ The impact of channel estimation error, phase discontinuity, spatial consistency, UE Speed, observation window, prediction window, CSI-RS periodicity.

· It has been studied with corresponding observations on complexity for both AI/ML based CSI prediction and non-AI/ML based CSI prediction.

· It has been studied on localized model including evaluation methodology, but is lack of observations.

· From the perspective of generalization over various scenarios,

o It has been studied with corresponding observations on (with the metric of SGCS):

§ the scenario including various UE speeds, deployment scenarios, carrier frequency

· From the perspective of performance monitoring, it has been studied on boundary between Type 1 and 3 performance monitoring, and potential specification impact for each performance monitoring type 1,2 and 3.

Observation

Based on the evaluation for CSI prediction, the following high-level observations are provided:

· From the perspective of basic performance gain over benchmark of non-AI/ML based CSI prediction, under the same UE speed for training and inference

o for AI/ML based CSI prediction over non-AI/ML based CSI prediction, [0%~7.8%] gain depending on traffic model, in terms of mean UPT, is observed by 7 sources

o for AI/ML based CSI prediction over non-AI/ML based CSI prediction, [3.8%~20.7%] gain depending on traffic model, in terms of 5% UE UPT, is observed by 7 sources.

· From a perspective of AI/ML complexity, 19 sources adopt the model subject to the computational complexity in units of FLOPs from 0.05M to 3000M. For complexity of non-AI/ML benchmark, 16 sources adopt the algorithm (e.g., Kalman filter, Auto-regression, Wiener filter) subject to the computational complexity in units of FLOPs from 0.14M to 107M. The ratio of FLOPs (AI/ML over benchmark 2) ranges from 1 to 35, which is used by majority sources. For non-AI/ML benchmark, main computation complexity is dominated by filter updates, which may not be need to be updated per inference at the expense of performance loss.

· From the perspective of performance impact on channel estimation error and phase discontinuity, compared to non-AI/ML CSI prediction, higher gain is observed by 10 sources for AI/ML based CSI prediction in the presence of channel estimation error or phase discontinuity.

· From the perspective of generalization over various scenarios/configurations (e.g., various UE speed, deployment scenario, carrier frequency) that have been evaluated, compared to generalization Case 1 where the AI/ML model is trained with dataset subject to a certain scenario#B/configuration#B and applied for inference with a same scenario#B/configuration#B

o For generalization Case 2 where the AI/ML model is trained with dataset from a different scenario#A/configuration#A, generalized performance may be achieved for some certain combinations of scenario#A/configuration#A and scenario#B/configuration#B but not for others.

o For generalization Case 3 where the training dataset is constructed with data samples subject to multiple scenarios/configurations including scenario#B/configuration#B, generalized performance of the AI/ML model can be achieved.

Agreement

From RAN1 perspective, study of CSI prediction has been completed and performance improvement is observed with increased complexity.

Final summary in R1-2407341.

9.1.3.2 CSI compression

R1-2405809 Discussion on additional study on AI/ML for NR air interface for CSI compression FUTUREWEI

R1-2405863 Discussion on AI/ML for CSI compression Huawei, HiSilicon

R1-2405901 Discussion on AIML for CSI compression Spreadtrum Communications, BUPT

R1-2405953 AI/ML based CSI Compression Google

R1-2405960 Discussion on AI/ML for CSI Compression Tejas Networks Limited

R1-2405978 Discussion on AI/ML for CSI compression CMCC

R1-2407186 AI/ML for CSI compression Intel Corporation (rev of R1-2406017)

R1-2406057 Discussion on study for AI/ML CSI compression ZTE Corporation, Sanechips

R1-2406069 AI/ML for CSI compression Ericsson

R1-2406175 Discussion on CSI compression vivo

R1-2406257 Additional study on AI/ML-based CSI compression OPPO

R1-2406272 Views on two-sided AI/ML model based CSI compression Xiaomi

R1-2406308 Discussion on CSI compression with AI/ML Fujitsu

R1-2407266 Further study on AI/ML for CSI compression CATT (rev of R1-2406356)

R1-2406392 Discussion on AI/ML for CSI compression Panasonic

R1-2406396 Discussions on AIML CSI compression TCL

R1-2406418 Study on CSI compression LG Electronics

R1-2406443 On AI/ML for CSI compression Lenovo

R1-2406466 Discussion on CSI compression Sony

R1-2406495 Additional study on AI-enabled CSI compression NVIDIA

R1-2406502 Discussion on AI/ML-based CSI compression InterDigital, Inc.

R1-2406534 Discussion on CSI compression NEC

R1-2406589 AI/ML for CSI Compression Nokia

R1-2406640 Discussion for further study on AI/ML-based CSI compression Samsung

R1-2406720 Discussion on AI/ML for CSI compression ETRI

R1-2406789 Additional study on AI/ML - CSI compression MediaTek Korea Inc.

R1-2406829 Discussion on AI based CSI compression Apple

R1-2406871 Discussion on AI/ML for CSI compression AT&T

R1-2406895 Discussions on AI/ML for CSI feedback CAICT

R1-2406923 Discussion on AI/ML for CSI compression NTT DOCOMO, INC.

R1-2407022 Additional study on CSI compression Qualcomm Incorporated

R1-2407065 Discussion on AI/ML for CSI Compression Indian Institute of Tech (M), IIT Kanpur

R1-2407077 Discussion on AI/ML for CSI Compression CEWiT

R1-2407121 Discussion on AI/ML based CSI compression ITL

R1-2407342 Summary#1 of Additional study on AI/ML for NR air interface: CSI compression Moderator (Qualcomm)

From Monday session

Agreement

For temporal domain aspects of AI/ML-based CSI compression using two-sided model in Release 19, among Cases 1, 2, 3, 4, and 5, prioritize further discussion on Case 2 and Case 3.

Agreement

For studying the standardization of model structure RAN1, RAN1 assumes at least the following:

· Precoding matrix as an input (as opposed to raw channel matrix)

o Per-layer processing, with common structure across ranks and layers (corresponding to Option 2-1, 2-2, 3-1, or 3-2 for handling rank ≥ 1)

· For temporal domain aspects Case 2 and Case 3, strive to reuse the model structure of Case 0 where appropriate, with additional layers or operations either at the input/output domain or at the latent domain.

· For Case 0, use precoding matrix, e.g., eigen vector in spatial-frequency domain, and/or angular, delay domain representation such as eType-II W2.

· For Case 2 and Case 3, use precoding matrix, e.g., spatial-frequency domain for each CSI observation instance, and/or angular, delay, and Doppler domain representation such as eType-II W2.

· Consider scalability approaches over numbers of Tx ports, CSI feedback payload sizes, and bandwidths.

R1-2407343 Summary#2 of Additional study on AI/ML for NR air interface: CSI compression Moderator (Qualcomm)

From Tuesday session

Observation

Option 5 alone doesn’t fully address inter-vendor collaboration complexity, but Option 5 has potential performance benefit and flexibility compared to Option 3.

R1-2407344 Summary#3 of Additional study on AI/ML for NR air interface: CSI compression Moderator (Qualcomm)

Presented in Wednesday session.

R1-2407433 Summary of Evaluation Results for AI/ML CSI compression Moderator (Qualcomm)

R1-2407345 Summary#4 of Additional study on AI/ML for NR air interface: CSI compression Moderator (Qualcomm)

From Thursday session

Agreement

For the evaluation of temporal domain aspects of AI/ML-based CSI compression using two-sided model in Release 19, for Case 2, study the performance impact resulting from non-ideal UCI feedback.

· Scenario A: no UCI loss

o Note: Corresponds to an upper bound or re-aligning missing historical CSI information

· Scenario B: UCI loss, known at NW and unknown at UE, with mitigation at NW

o Note: Corresponds to implementation-based mitigation at NW but no signaling to UE.

· Scenario C: UCI loss, known at NW and UE, with mitigation at NW and UE

o Note: Corresponds to reset of historical CSI information at both UE and NW or any other mitigation approach enabled by signaling.

· UCI loss modeling

o 10% UCI loss probability on all UCI reports

o Other options are not precluded, e.g., No UCI loss for the first UCI report of each observation window, and 10% UCI loss probability for the subsequent reports of each observation window, as a shortcut to simplify the evaluation work.

o Other values for UCI loss probability are not precluded.

· Note: The same UCI loss modeling shall be applied to the benchmark for fair comparison.

· FFS: partial PMI-related UCI loss

R1-2407499 Updated summary of Evaluation Results for AI/ML CSI compression Moderator (Qualcomm)

R1-2407346 Summary#5 of Additional study on AI/ML for NR air interface: CSI compression Moderator (Qualcomm)

Agreement

Adopt all the observations in Section 2 of R1-2407499.

Agreement

Continue the study of following directions - on-device operation and UE side offline engineering

· Direction A: Sharing parameters/reference model/dataset that enables UE-side offline engineering (Inter vendor collaboration option 3a/5a/4)

o Potential down-selection into one or more among sub-options 3a/5a-1, 3a/5a-2, 3a/5a-3, 4-1, 4-2, and 4-3 considering their feasibility and performance, including at least the following issues

§ [Issue 1] What additional information should be shared from NW-side to UE-side to enable UE-side encoder training, validation, and testing?

§ [Issue 2] Is there concern for NW’s proprietary information disclosure, and if so, how to address it?

§ [Issue 3] Is there an overhead concern, and if so, how to address it?

§ [Issue 4] Is there performance impact due to mismatch between NW side data distribution and UE side data distribution, and if so, how to address it?

· Direction B: Sharing NW side encoder parameter to UE side for UE side inference directly with on-device operation (Inter vendor collaboration option 3b), including at least the following issues

o [Issue 3] Is there an overhead concern, and if so, how to address it?

o [Issue 5] Whether it is feasible to use a common encoder across UEs, and whether it is feasible for NW-side to train multiple encoders for different UEs?

o [Issue 6] Is there performance impact due to mismatch between NW side data distribution and UE side inference data distribution, and if so, how to address it?

o [Issue 7] Is there concern for NW’s and UE’s proprietary information disclosure, and if so, how to address it?

· Direction C: Fully standardized reference model(s) and parameters with specified CSI generation part and/or CSI reconstruction part (Inter vendor collaboration option 1), including at least the following issues

o [Issue 8] Whether to consider 3GPP’s statistical channel model or field data for reference model(s) training. In case of the latter, how does RAN1 collect field data and agree on them?

o [Issue 9] Is there performance impact due to mismatch between the distribution of the dataset used for reference model(s) training, UE-side data distribution, and NW-side data distribution, and if so, how to address it?

o [Issue 10] What additional information should be specified to enable UE-side encoder training, validation, and testing, and UW-side decoder training, validation, and testing?

o Note:

§ 1-1: Only reference encoder is specified, and NW-side and/or UE-side may train their actual CSI generation part and NW-reconstruction part separately compatible to the reference encoder.

§ 1-2: Only reference decoder is specified, and NW-side and/or UE-side may train their actual CSI generation part and NW-reconstruction part separately compatible to the reference decoder.

§ 1-3: Both reference encoder and reference decoder are specified, and NW-side and/or UE-side may train their actual CSI generation part and NW-reconstruction part separately that are compatible to the reference decoder/encoder.

· Note: UE-side data and NW-side data in “UE-side data distribution” and “NW-side data distribution” are field data.

· Note: Some issues identified in one direction may/may not be applicable for other Direction.

· Note: potential down selection among the 3 directions is not precluded

· Study of data distribution mismatch to consider the use of synthetic data and/or field data.

Agreement

According to the Rel-19 study objective,

o For CSI compression (two-sided model), further study ways to:

§ Improve trade-off between performance and complexity/overhead

· e.g., considering extending the spatial/frequency compression to spatial/temporal/frequency compression, cell/site specific models, CSI compression plus prediction (compared to Rel-18 non-AI/ML based approach), etc.

§ Alleviate/resolve issues related to inter-vendor training collaboration.

while addressing other aspects requiring further study/conclusion as captured in the conclusions section of the TR 38.843.

RAN1 is recommending extending the study of the AI/ML CSI compression, based on RAN1 understanding the study on CSI compression is not completed.

R1-2407495 Summary#6 of Additional study on AI/ML for NR air interface: CSI compression Moderator (Qualcomm)

Presented in Friday session.

Final summary in R1-2407347.

9.1.3.33 Other aspects of AI/ML model and data

Including model identification/procedure, collection of UE-sided model training data, and model transfer/delivery

R1-2405810 Discussion on other aspects of AI/ML model and data on AI/ML for NR air-interface FUTUREWEI

R1-2405902 Discussion on other aspects of AI/ML model and data Spreadtrum Communications

R1-2405954 AI/ML Model and Data Google

R1-2405962 Other aspects of AI/ML Model and Data Tejas Networks Limited

R1-2405979 Discussion on other aspects of AI/ML model and data CMCC

R1-2406018 Other study aspects of AI/ML for air interface Intel Corporation

R1-2406058 Discussion on other aspects of AI/ML model and data ZTE Corporation, Sanechips

R1-2406064 Discussion on other aspects of AI/ML model and data Continental Automotive

R1-2406142 Discussion on other aspects of AI/ML Ericsson

R1-2406176 Other aspects of AI/ML model and data vivo

R1-2406258 Additional study on other aspects of AI/ML model and data OPPO

R1-2406273 Further study on AI/ML model and data Xiaomi

R1-2406309 Discussion on other aspects of AI/ML model and data Fujitsu

R1-2406357 Further study on AI/ML for other aspects CATT, CICTCI

R1-2406397 Discussions on Other Aspects of AIML in NR air interface TCL

R1-2406419 Discussion on other aspects of AI/ML model and data LG Electronics

R1-2406444 Discussion on other aspects of AI/ML model and data Lenovo

R1-2406459 Discussion on other aspects of AI/ML model and data IIT Kanpur

R1-2406496 Additional study on other aspects of AI model and data NVIDIA

R1-2406503 Discussion on other aspects of AI/ML model and data InterDigital, Inc.

R1-2406542 Discussion on other aspects of AI/ML model and data NEC

R1-2406590 Other Aspects of AI/ML Model and Data Nokia

R1-2406641 Discussion for further study on other aspects of AI/ML model and data Samsung

R1-2406674 Discussion on other aspects for AI/ML for air interface Panasonic

R1-2406721 Discussion on other aspects of AI/ML model and data ETRI

R1-2406830 Discussion on other aspects of AI/ML model and data Apple

R1-2406872 Other Aspects of AI/ML framework AT&T

R1-2406889 Other Aspects of AI/ML Model and Data Meta Ireland

R1-2406924 Discussion on other aspects of AI/ML model and data NTT DOCOMO, INC.

R1-2406964 Discussion on other aspects of AI/ML model and data Sharp

R1-2406976 Discussion on other aspects of the additional study for AI/ML Huawei, HiSilicon

R1-2407023 Other aspects of AI/ML model and data Qualcomm Incorporated

R1-2407302 Summary #1 for other aspects of AI/ML model and data Moderator (OPPO)

From Tuesday session

Conclusion

From RAN1 perspective, model identification is at least applicable to some of inter-vendor training collaboration option(s) of CSI compression using two-sided model (if supported).

Conclusion

The model identification procedure dedicated to MI-Option5 is not pursued for Rel-19 normative work.

Conclusion

The model identification procedure dedicated to MI-Option2 for one-sided model is not pursued for Rel-19 normative work.

Agreement

Confirm the following Working assumption.

Working Assumption

Regarding the associated ID for Rel-19, the UE assumes that NW-side additional conditions with the same associated ID are consistent at least within a cell

· FFS: whether/how UE assumption can be applicable for multiple cells (including the feasibility study)

Agreement

From RAN1 perspective, the “known model structure(s)” of the model transfer/delivery Case z4 at least include known information on the following aspects

· Model type/backbone (e.g., Transformer, CNN and so on)

· In case model type is a neural network

o Number of layers

o Layer types/structure (e.g., full connected, activation layer and so on)

o Layer size (e.g., the number of parameters of a layer)

o Connection between different layers

· model input/output related information

R1-2407303 Summary #2 for other aspects of AI/ML model and data Moderator (OPPO)

From Wednesday session

Conclusion

From RAN1 perspective, model transfer is needed at least for some (e.g., Option 3b) of inter-vendor training collaboration option(s) of CSI compression using two-sided model (if supported).

R1-2407304 Summary #3 for other aspects of AI/ML model and data Moderator (OPPO)

From Thursday session

Agreement

RAN1 is recommending extending the study of the Model identification, and Model transfer/Model delivery based on RAN1 understanding the study is not completed.

R1-2407520 TPs to capture the outputs of 9.1.3.3 Moderator (OPPO)

From Friday session

Agreement

Adopt the TP1, TP2, TP3 and TP4 in Section 2 of R1-2407520 in principle.

Final summary in R1-2407305.

RAN1#118-bis

9.1 Artificial Intelligence (AI)/Machine Learning (ML) for NR Air Interface

Please refer to RP-242399 for detailed scope of the WI. Additional RAN guidance on Rel-18 AI/ML for NR Air Interface can be found in RP-242387.

R1-2409222 Session notes for 9.1 (AI/ML for NR Air Interface) Ad-Hoc Chair (CMCC)

Friday decision: The session notes are endorsed and contents reflected below.

[118bis-R19-AI/ML] – Taesang (Qualcomm)

Email discussion on Rel-19 AI/ML

- To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc

9.1.1 Specification support for beam management

R1-2407616 Discussion on specification support for AI/ML-based beam management FUTUREWEI

R1-2407653 Discussion on AI/ML for beam management Huawei, HiSilicon

R1-2407694 Discussion on AIML for beam management Spreadtrum Communications

R1-2407728 Discussion on AI/ML for beam management China Telecom

R1-2407746 Specification support for beam management Tejas Network Limited

R1-2407796 Discussion on AI/ML-based beam management ZTE Corporation, Sanechips

R1-2407848 Specification support for beam management vivo

R1-2407892 Discussion on specification support for beam management CMCC

R1-2407938 Discussion on AIML beam management TCL

R1-2407950 Specification support for beam management Xiaomi

R1-2407988 AI/ML based Beam Management Google

R1-2408027 Discussion on AI/ML-based beam management CATT

R1-2408103 Discussion on specification support for beam management Fujitsu

R1-2408116 Discussion on specification support for AI/ML beam management Transsion Holdings

R1-2408158 On specification for AI/ML-based beam management OPPO

R1-2408221 Discussion on specification support for beam management NEC

R1-2408268 AI/ML for beam management Ericsson

R1-2408279 Discussion on AI/ML for beam management InterDigital, Inc.

R1-2408289 Specification support for AI/ML for beam management Intel Corporation

R1-2408332 Discussions on AI/ML for beam management LG Electronics

R1-2408365 Specification support for beam management Fraunhofer HHI, Fraunhofer IIS

R1-2408380 Discussion on specification support for beam management Ruijie Networks Co. Ltd

R1-2408390 Specification support for AI-enabled beam management NVIDIA

R1-2408401 Discussions on AI/ML for beam management Sony

R1-2408428 AI/ML specification support for beam management Lenovo

R1-2408452 Discussion on AI/ML beam management Apple

R1-2408533 Discussion on specification support for beam management Panasonic

R1-2408544 AI/ML for Beam Management Nokia

R1-2408558 Discussion on specification support for beam management ETRI

R1-2408608 Discussions on specification support for beam management Sharp

R1-2408630 Discussion for supporting AI/ML based beam management Samsung

R1-2408689 Discussion on Beam management Rakuten Mobile, Inc

R1-2408690 Specification Support for AI/ML for Beam Management Kyocera Corporation (rev of R1-2407690)

R1-2408704 Discussion on specification support for AIML-based beam management MediaTek Inc.

R1-2408749 AI/ML for Beam Management Meta

R1-2408753 Discussion on AI/ML based beam management KT Corp.

R1-2408773 Discussion on AI/ML for beam management NTT DOCOMO, INC.

R1-2408806 Discussions on AI/ML for beam management CAICT

R1-2408823 Specification support for beam management KDDI Corporation

R1-2408837 Specification support for AI-ML-based beam management Qualcomm Incorporated

R1-2408887 On Associated ID for Beam Management Use Case NTU

R1-2408922 Discussion on Incoming LS on applicable functionality reporting for beam management with UE-sided model Indian Institute of Tech (M), IIT Kanpur

R1-2408959 Specification support for AI/ML beam management ITL

From AI 5

R1-2407604 LS on applicable functionality reporting for beam management UE-sided model RAN2, Intel

Decision: RAN1 response to be handled in agenda item 9.1.1. To be moderated by Feifei (Samsung).

R1-2409114 FL summary #0 for AI/ML in beam management Moderator (Samsung)

R1-2409115 FL summary #1 for AI/ML in beam management Moderator (Samsung)

From Tuesday session

Agreement

Answer to Q2 in R1-2407604 as below:

RAN 1 did not have agreement on the content of NW-side additional condition. RAN1 agreed to support associated ID and it can be used to ensure the consistency of NW-side additional condition across training and inference for UE-sided model for BM-Case 1 and BM Case 2. UE may assume the similar properties of a DL Tx beam or beam set/list associated with the same associated ID, while FFS whether/how to define similar properties of a DL Tx beam or beam set/list.

Agreement

For BM-Case1 and BM-Case2 with a UE-sided AI/ML model, for Option 2 (UE-assisted performance monitoring),

At least support Alt 1: Top 1 or Top K beam prediction accuracy (with or without margin) by comparing the prediction results and the Top 1 or Top K beam based on the measurements from a resource set/ resources for monitoring

FFS on detail definition of the metric, including whether/how to configure or define a window for calculation
FFS: on other details including how to configure the resource set/resources for monitoring, including

§ E.g. whether/how to use full set of Set A for measurement. If the full set A is not configured, whether/how to define the metric

FFS other alternatives

Agreement

For BM-Case 2 of UE-side model, for the reference time of the earliest time instance for the predicted results, consider at least the following alternatives for potential down-selection:

Option 1: Based on the uplink slot for the report
Option 2: Based on the CSI reference resource corresponding to the report
Option 3: Based on the latest transmission occasion of the CSI-RS/SSB resource in Set B for measurement for the report, wherein the transmission occasion is no later than the CSI reference resource

Agreement

For UE-side model, existing CPU mechanism is used as a starting point for AI/ML-based CSI processing.

FFS whether the overall CPU should be shared or separately counted between legacy CSI reporting and AI/ML-based CSI reporting, and among AI/ML features/functionalities.
FFS whether it is fully applicable for BM-Case 1 and/or BM-Case 2.

Agreement

For UE-side AI/ML model, for BM-Case1, at least for inference, at least for Set B, support the following CSI-RS resource types for CMR:

Periodic (P) CSI-RS
Semi-persistent (SP) CSI-RS
Aperiodic (AP) CSI-RS

For UE-side AI/ML model, for BM-Case 2, at least for inference, at least for Set B, support the following CSI-RS resource types for CMR:

Periodic (P) CSI-RS
Semi-persistent (SP) CSI-RS
FFS: Aperiodic (AP) CSI-RS

Note: above CSI-RS resource refers to that used for beam management.

R1-2409116 FL summary #2 for AI/ML in beam management Moderator (Samsung)

From Wednesday session

Agreement

At least for the monitoring Type 1 Option 2 of UE-side model monitoring (when applicable), consider the following options with potential down selection for the configuration for monitoring:

Option 1: The resource set(s) for monitoring and report configuration for monitoring are configured (when applicable) within CSI report configuration used for inference

FFS: the resource set(s) for monitoring
UE measures the resource set(s) for monitoring.
FFS how/when to report the monitoring results.

Option 2: Dedicated resource set(s) for monitoring and report configuration for monitoring are configured in a dedicated CSI report configuration used for monitoring

The dedicated report configuration used for monitoring links to an inference report configuration

FFS how to identify the connection between RSs in the resource set(s) for monitoring and Set A beams

UE measures the resource set(s) for monitoring.
FFS when to report the monitoring results.

R1-2409117 FL summary #3 for AI/ML in beam management Moderator (Samsung)

Presented in Thursday session.

R1-2409118 FL summary #4 for AI/ML in beam management Moderator (Samsung)

From Friday session

Agreement

RAN 1 further study the following options for applicability for inference for UE-side model:

Option 1:

In Step 3, following configurations are provided from NW to UE:

1) UE is allowed to do UAI reporting via OtherConfig,
2)+3) NW configures one or more CSI-ReportConfig for inference configuration, where the associated ID may be configured in CSI framework as working assumption applied.
FFS on whether some IEs in the CSI report configuration can be removed or modified
Note: CSI report configuration for UE-side model inference can’t be activated immediately upon receiving Step 3

In Step 4, UE reports applicability(ies) of the above CSI-ReportConfig

FFS on one or more of the above CSI-ReportConfig to be reported

FFS on activation (including when/how) of inference report after obtaining the applicability from UE Step 4
FFS: whether Step 5 is needed,

Option 2:

In Step 3, following configurations are provided from NW to UE:

UE is allowed to do UAI reporting via OtherConfig,
NW configures one set or multiple sets of inference related parameters

Note: the set of inference related parameters is not configured by CSI-ReportConfig
FFS on the set of inference related parameters, at least including:

Set A related information
Set B related information
Report content related information
For BM-Case 2,

Time instances related information for measurements
Time instances related information for prediction

The associated ID(s) may be configured

wherein the associated ID(s) may be

§ FFS: a) part of one set of the inference related parameters, or

FFS: b) independently from the one set of the inference related parameters.

In Step 4, UE reports applicability of the above one or multiple sets of inference related parameters, where the associated ID information may be associated.
In Step 5, NW configures configuration(s) for CSI report for inference

Option 3:

In Step 3, following configurations are provided from NW to UE:

1) UE is allowed to do UAI reporting via OtherConfig,
2) The associated ID(s) may be provided to UE, e.g., a new RRC parameter.

In Step 4, UE reports by UAI

the applicable one or multiple sets of inference related parameters may be included.

FFS on the set of inference related parameters, at least including:

Set A related information
Set B related information
Report content related information
For BM-Case 2,

Time instances related information for measurements
Time instances related information for prediction

Note: not applicable may also be replied by UE
Note: if the inference related parameters are not supported for reporting, only the applicability(ies) or not is reported in Step 4.

the associated ID(s) may be included

FFS: a) as part of the inference related parameters, or
FFS: b) independently from the set of the inference related parameters.

In Step 5, NW configures configuration(s) for CSI report for inference.

Note: There is no impact of configuring CSI report configuration for non-AI beam management in RRCReconfiguration.

Agreement

For UE-side model, for beam management, for inference report, support periodic CSI report, aperiodic CSI report, and semi-persistent CSI report.

Agreement

For beam management, multiple CSI reports for inference for UE-side model can be configured/activated/triggered, which is up to UE capability.

Agreement

Incorporating below text into the general part of the LS

In RAN1’s discussion of RAN 2 terminologies on beam management,

The concept/terminology “functionality“ of Supported functionalities may refer to UE-capability information/parameters i.e., Rel-19 AI/ML-specific FGs
The concept/terminology “ functionality“ of Applicable functionalities may refer to CSI-ReportConfig for inference configuration or a set of inference related parameters or information/parameters indicated by UE

· The Activated functionalities may be enabled based on CSI framework.

Therefore, the meaning and the granularity of “functionality“ for Applicable functionalities, Activated functionalities and Supported functionalities may or may not be the same, depends on certain option in RAN1, and the discussion is still ongoing.

Agreement

Answer to Q1 in R1-2407604 as below,

In Step 2, RAN1 expects that UE reports its UE-capability information/parameters, i.e., Rel-19 AI/ML-specific FGs (including components and corresponding value ranges). These AI/ML-specific UE capability information/parameters will depend on how FGs are defined including the granularity, that will be discussed in RAN1 later in the WI.

Final summary in R1-2409305.

9.1.2 Specification support for positioning accuracy enhancement

R1-2407649 AI/ML for Positioning Accuracy Enhancement Ericsson

R1-2407654 Discussion on AI/ML for positioning accuracy enhancement Huawei, HiSilicon

R1-2407747 Specification support for positioning accuracy enhancement Tejas Network Limited

R1-2407797 Discussion on AI/ML-based positioning enhancement ZTE Corporation, Pengcheng Laboratory

R1-2407849 Specification support for positioning accuracy enhancement vivo

R1-2407893 Discussion on specification support for positioning accuracy enhancement CMCC

R1-2407951 Discussion on AI/ML-based positioning accuracy enhancement Xiaomi

R1-2407989 AI/ML based Positioning Google

R1-2408028 Discussion on AI/ML-based positioning CATT, CICTCI

R1-2408104 Discussion on specification support for AI/ML-based positioning accuracy enhancement Fujitsu

R1-2408159 On specification for AI/ML-based positioning accuracy enhancements OPPO

R1-2408214 Discussion on specification support for AIML based positioning accuracy enhancement NEC

R1-2408267 Discussion on specification support for positioning accuracy enhancement TCL

R1-2408290 Specification support for AI/ML for positioning accuracy enhancement Intel Corporation

R1-2408309 Specification support for positioning accuracy enhancement Baicells

R1-2408381 Discussion on specification support for positioning accuracy enhancement Ruijie Networks Co. Ltd

R1-2408385 AI/ML positioning accuracy enhancement Fraunhofer IIS, Fraunhofer HHI

R1-2408391 Specification support for AI-enabled positioning NVIDIA

R1-2408402 Support for AI/ML for positioning accuracy enhancement Sony

R1-2408429 Specification impacts for AI/ML positioning Lenovo

R1-2408453 Discussion on Specification Support for AI/ML-based positioning Apple

R1-2408522 Discussion on support for AIML positioning InterDigital, Inc.

R1-2408545 AI/ML for Positioning Accuracy Enhancement Nokia

R1-2408559 Discussion on specification support for positioning accuracy enhancement ETRI

R1-2408609 Discussion on specification support for AI/ML based positioning accuracy enhancements Sharp

R1-2408631 Discussion for supporting AI/ML based positioning accuracy enhancement Samsung

R1-2408774 Discussion on AI/ML for positioning accuracy enhancement NTT DOCOMO, INC.

R1-2408838 Specification support for AI-ML-based positioning accuracy enhancement Qualcomm Incorporated

R1-2408903 Design for AI/ML based positioning MediaTek Korea Inc.

R1-2408908 Discussions on specification support for positioning accuracy enhancement for AI/ML ITL

R1-2408923 Discussion on specification support for AI/ML Positioning Accuracy enhancement CEWiT

R1-2409028 Summary #1 of specification support for positioning accuracy enhancement Moderator (Ericsson)

From Monday session

Agreement

For training data collection of AI/ML based positioning, the quality indicator of timing information in Part A when reported is:

· When applicable, the existing IE for timing quality, i.e., NR-TimingQuality in 37.355 and IE “Timing Measurement Quality” in 38.455;

o FFS: details on how to associate quality indicator to timing information

Conclusion

For training data collection of Case 1, in terms of DL PRS configuration for collecting training data, both options are feasible by using legacy mechanisms:

· Option A: (UE initiated) UE makes a request to LMF on the preferred DL PRS configuration for training data collection, e.g., on-demand PRS. LMF makes the decision on determining the DL PRS configuration for training data collection and provides the assistance data to the UE.

· Option B: (LMF initiated) LMF determines the DL PRS configuration for training data collection and provides the assistance data to the UE.

Note: the UE can be a PRU and/or a Non-PRU UE.

Note: as in existing specification, the DL PRS configurations in the assistance data from LMF to UE are based on DL PRS configuration coordinated between LMF and gNB.

R1-2409029 Summary #2 of specification support for positioning accuracy enhancement Moderator (Ericsson)

From Tuesday session

Agreement

From RAN1 perspective, for model inference of AI/ML positioning Case 3b, at least the following are mandatorily or optionally supported in a measurement report from gNB to LMF:

(Mandatory) Channel measurement;
(Optional) Quality of the channel measurement;

FFS: details of the quality

(Mandatory) Time stamp of the channel measurement.

R1-2409030 Summary #3 of specification support for positioning accuracy enhancement Moderator (Ericsson)

Presented in Wednesday session.

R1-2409031 Summary #4 of specification support for positioning accuracy enhancement Moderator (Ericsson)

From Thursday session

Agreement

From RAN1 perspective, when timing information is reported for Rel-19 AI/ML positioning Case 3a, at least the following are mandatorily or optionally supported in a measurement report from gNB to LMF:

(Mandatory) timing information;
(Optional) Quality of the timing information;

Existing IE “Timing Measurement Quality” can be reused.

(Mandatory) Time stamp.

FFS: LOS/NLOS indicator.

Note: The final decision of “mandatory” or “optional” presence of each field is up to RAN3.

R1-2409032 Summary #5 of specification support for positioning accuracy enhancement Moderator (Ericsson)

From Friday session

Agreement

For AI/ML positioning Case 1, regarding the assistance data provided from LMF to UE, for ensuring consistency between training and inference,

· for each of the existing assistance data IE of UE-based DL-TDOA and/or UE-based DL-AoD, study whether it should be: (a) explicitly indicated, (b) implicitly indicated and/or (c) other;

· Companies can provide inputs on further enhancements of existing assistance data, including new information

· Note: this does not mean that training and inference phases are mentioned in assistance data.

Table. Existing assistance data (supported up to Rel-18) that may be transferred from LMF to UE in UE-based DL-TDOA [1] or UE-based DL-AoD [2], as applicable.

	Information	UE-based DL-TdoA	UE-based DL-AoD
1	Physical cell IDs (PCIs), global cell IDs (GCIs), ARFCN, and PRS IDs of candidate NR TRPs for measurement
2	Timing relative to the serving (reference) TRP of candidate NR TRPs
3	DL-PRS configuration of candidate NR TRPs
4	Indication of which DL-PRS Resource Sets across DL-PRS positioning frequency layers are linked for DL-PRS bandwidth aggregation
5	SSB information of the TRPs (the time/frequency occupancy of SSBs)
6	Spatial direction information (e.g. azimuth, elevation etc.) of the DL-PRS Resources of the TRPs served by the gNB
7	Geographical coordinates of the TRPs served by the gNB (include a transmission reference location for each DL-PRS Resource ID, reference location for the transmitting antenna of the reference TRP, relative locations for transmitting antennas of other TRPs)
8	Fine Timing relative to the serving (reference) TRP of candidate NR TRPs
9	PRS-only TP indication
10	The association information of DL-PRS resources with TRP Tx TEG ID
11	LOS/NLOS indicators
12	On-Demand DL-PRS-Configurations, possibly together with information on which configurations are available for DL-PRS bandwidth aggregation
13	Validity Area of the Assistance Data
14	PRU measurements together with the location information of the PRU
15	Data facilitating the integrity results determination of the calculated location
16	TRP beam/antenna information (including azimuth angle, zenith angle and relative power between PRS resources per angle per TRP)
17	Expected Angle Assistance information
18	PRS priority list

[1] Table 8.12.2.1.0-1 in 38.305, Use equipment (UE) positioning in NG-RAN (Release 18), v18.3.0

[2] Table 8.11.2.1.0-1 in 38.305, Use equipment (UE) positioning in NG-RAN (Release 18), v18.3.0

Final summary in R1-2409286.

9.1.3 Specification support for CSI prediction

Discussions on RAN1#118bis and RAN1#119 will be limited to the study on consistency of training/inference.

R1-2407655 Discussion on AI/ML for CSI prediction Huawei, HiSilicon

R1-2407695 Discussion on AIML for CSI prediction Spreadtrum Communications

R1-2407798 Discussion on specification support for AI CSI prediction ZTE Corporation, Sanechips

R1-2407850 Study on consistency issue for csi prediction vivo

R1-2407894 Discussion on AI/ML for CSI prediction CMCC

R1-2407939 Discussions on AIML CSI prediction TCL (Late submission)

R1-2407952 Discussion on UE-side AI/ML model based CSI prediction Xiaomi

R1-2407990 AI/ML based CSI Prediction Google

R1-2408029 Discussion on AI/ML-based CSI prediction CATT

R1-2408080 AI/ML for CSI prediction Ericsson

R1-2408105 Discussion on specification support for CSI prediction Fujitsu

R1-2408160 On specification for AI/ML-based CSI prediction OPPO

R1-2408212 Discussion on specification support for CSI prediction NEC

R1-2408247 AI/ML for CSI prediction Mavenir

R1-2408333 Discussions on CSI prediction LG Electronics

R1-2408362 Discussion on consistency of training / inference for AI/ML-based CSI prediction Panasonic

R1-2408392 Specification support for AI-enabled CSI prediction NVIDIA

R1-2408403 Input quantities for CSI prediction model training, inference and monitoring Sony

R1-2408430 On AI/ML for CSI prediction Lenovo

R1-2408436 On AI/ML-based CSI prediction InterDigital, Inc.

R1-2408454 Discussion on AI based CSI prediction Apple

R1-2408546 AI/ML for CSI Prediction Nokia

R1-2408597 Discussion on Specification support for CSI prediction Tejas Network Limited

R1-2408632 Views on AI/ML based CSI prediction Samsung

R1-2408688 Discussion on CSI feedback enhancement Rakuten Mobile, Inc

R1-2408694 Specification support for CSI prediction MediaTek Inc.

R1-2408759 Discussion on AI/ML for CSI prediction AT&T

R1-2408775 Discussion on AI/ML for CSI prediction NTT DOCOMO, INC.

R1-2408839 Specification support for CSI prediction Qualcomm Incorporated

R1-2409144 Summary #1 of CSI prediction Moderator (LG Electronics)

From Monday session

Agreement

For consistency between training and inference, study to identify which potential NW-side additional conditions, if any, may impact on UE assumption for CSI prediction using UE-sided model, resulting non-negligible degradation on model generalization performance.

Note: Companies are encouraged to provide generalization performance evaluation on the impact of NW-side additional conditions, if considered.

R1-2409145 Summary #2 of CSI prediction Moderator (LG Electronics)

From Wednesday session

Agreement

For generalization evaluation to identify potential NW-side additional conditions to ensure consistency between training and inference, consider one or more of the following aspects, if evaluated:

[Optional evaluation] Various tilt angle (e.g., [102] degrees, [110] degrees)
[Optional evaluation] Various TXRU mapping

With TXRU virtualization (e.g., for 32 port CSI-RS, [N1, N2, P] = [2, 8, 2] (baseline), [4,4,2] (optional) with (8x8x2) and (12 x 8 x 2) antenna elements)
Without TXRU virtualization (e.g., for 32 port CSI-RS, [N1, N2, P] = [2, 8, 2] (baseline), [4,4,2] (optional) with (2x8x2) and (4 x 4 x 2) antenna elements, respectively)

Other configurations are not precluded

Note: for other evaluation assumptions, reuse baseline of TR 38.843.

Note: report how to map antenna port to antenna elements.

Note: report the backbone/structure of AI/ML model used.

R1-2409236 Text proposals to capture the outputs of study on CSI prediction Moderator (LG Electronics)

From Thursday session

Agreement

The TP1, TP2 and TP3 to TR38.843 in Section 3 of R1-2409236 are endorsed in principle.

Final summary in:

R1-2409146 Summary #3 of CSI prediction Moderator (LG Electronics)

9.1.4 Additional study on AI/ML for NR air interface

9.1.4.1 CSI compression

R1-2407617 Discussion of additional study on AI/ML for NR air interface for CSI compression FUTUREWEI

R1-2407656 Discussion on AI/ML for CSI compression Huawei, HiSilicon

R1-2407696 Discussion on AIML for CSI compression Spreadtrum Communications, BUPT

R1-2407748 CSI compression Tejas Network Limited

R1-2407799 Discussion on study for AI/ML CSI compression ZTE Corporation, Sanechips

R1-2407851 Discussion on CSI compression vivo

R1-2407895 Discussion on AI/ML for CSI compression CMCC

R1-2407940 Discussion on AIML CSI compression TCL

R1-2407953 Views on two-sided AI/ML model based CSI compression Xiaomi

R1-2407991 AI/ML based CSI Compression Google

R1-2408030 Study on AI/ML-based CSI compression CATT

R1-2408079 AI/ML for CSI compression Ericsson

R1-2408084 Discussion on AI/ML for CSI compression BJTU (Late submission)

R1-2408106 Discussion on CSI compression Fujitsu

R1-2408161 Additional study on AI/ML-based CSI compression OPPO

R1-2408213 Discussion on CSI compression NEC

R1-2408291 AI/ML for CSI compression Intel Corporation

R1-2408334 Study on CSI compression LG Electronics

R1-2409007 Discussion on AI/ML for CSI compression Panasonic (rev of R1-2408363)

R1-2408393 Additional study on AI-enabled CSI compression NVIDIA

R1-2408431 On AI/ML for CSI compression Lenovo

R1-2408437 On AI/ML-based CSI compression InterDigital, Inc.

R1-2408455 Discussion on AI based CSI compression Apple

R1-2408547 AI/ML for CSI Compression Nokia

R1-2408560 Discussion on AI/ML for CSI compression ETRI

R1-2408633 Views on additional study for AI/ML based CSI compression Samsung

R1-2408695 Additional study on AI/ML for NR air interface - CSI compression MediaTek Inc.

R1-2408776 Discussion on AI/ML for CSI compression NTT DOCOMO, INC.

R1-2408807 Discussions on AI/ML for CSI compression CAICT

R1-2408840 Additional study on CSI compression Qualcomm Incorporated

R1-2408924 Discussion on AI/ML for CSI compression CEWiT

R1-2408952 Discussion on AI/ML for CSI compression IIT Kanpur

R1-2409156 Summary#1 of Additional study on AI/ML for NR air interface: CSI compression Moderator (Qualcomm)

From Monday session

Conclusion

For issues listed for inter-vendor collaboration Direction A, conclude the following

Answer to Issue 2: From RAN1 perspective, at least,

For option 4-1, there is no proprietary information concern of disclosing encoder input/output from NW side to UE side
For option 3a-1, there is no proprietary information concern of disclosing encoder parameters from NW side to UE side
Note: If some additional information is disclosed from network side to UE side, proprietary concerns for option 4-1 and 3a-1 can not be precluded by default.

R1-2409157 Summary#2 of Additional study on AI/ML for NR air interface: CSI compression Moderator (Qualcomm)

R1-2409158 Summary#3 of Additional study on AI/ML for NR air interface: CSI compression Moderator (Qualcomm)

R1-2409159 Summary#4 of Additional study on AI/ML for NR air interface: CSI compression Moderator (Qualcomm)

From Wednesday session

Agreement

For issues listed for inter-vendor collaboration direction B, further study the overhead in Direction B based on the size of the encoder (i.e., number of parameters and quantization level), the number of encoders, and how often the parameters need to be transferred.

Agreement

For Directions of addressing inter-vendor collaboration complexity for two-sided CSI compression,

For Direction A:

Further study the following options with potential down-selection

4-1: dataset is {target CSI, CSI feedback},
3a-1: encoder parameter exchange, with {target CSI}
Note: Additional information beyond what’s listed above may need to be exchanged if necessary.

Agreement

For Direction C:

It is clarified that, the purpose of a fully specified CSI generation (reconstruction) part is to enable development/training of compatible CSI reconstruction (generation) parts at the NW (UE) side.
Study whether the fully specified reference models or their compatible models may provide reasonable performance for deployment at NW and UE

Including performance evaluation of training/finetuning the models by modeling data distribution mismatch between synthetic and field data, and/or by using actual field data
Including performance evaluation of training/finetuning the models by modelling data distribution mismatch between NW-side field data and UE-side field data, and/or by using actual field data from both NW-side and UE-side
Note: Training/finetuning is done at either or both sides without inter-vendor collaboration.

FFS whether the reference model is the encoder (1-1) or decoder (1-2) or both (1-3)
FFS whether the reference model is the same as RAN4 specified model
FFS whether a single or multiple reference (and how many) models need to be specified

Agreement

For the evaluation studies of Direction A,

For encoder parameter exchange from NW-side to UE-side of 3a-1,

Alt. 1: UE-side first trains a nominal decoder

Step 1: UE-side develops a nominal decoder against the exchanged encoder.
Step 2: UE-side develops actual encoder against the nominal decoder

Alt. 2: UE-side directly develops and trains the actual encoder.
Note: Target CSI is available at UE side

For dataset exchange from NW-side to UE-side {target CSI, CSI feedback} of 4-1,

Alt. 1: UE-side first trains a nominal decoder

Step 1: UE-side develops a nominal decoder using the exchanged dataset.
Step 2: UE-side develops an actual encoder against the nominal decoder.

Alt. 2: UE-side directly develops and trains the actual encoder.

R1-2409160 Summary#5 of Additional study on AI/ML for NR air interface: CSI compression Moderator (Qualcomm)

From Thursday session

Agreement (further amended on Friday as shown in red)

For discussion on performance degradation due to UE-side / NW-side data distribution mismatch with respect to UE side additional condition (issue 4 and 6), consider

NW-side data (dataset A) and UE-side data (dataset B) are mismatched in terms of UE-side additional condition (e.g., SVD phase normalization method, UE antenna virtualization, antenna imbalance, antenna spacing / layout, etc)

Note: dataset A may or may not contain dataset B
Note: if dataset A includes dataset B, this means NW timely collect data from the UE
Note: Dataset A and dataset B are aligned in terms of NW-side additional conditions.

Case 1: An encoder-decoder pair is trained on dataset B. This serves as an upper-bound.
Case 2 (for direction A):

For direction A: NW-side trains a decoder on dataset A, and UE-side trains an encoder based on either dataset A, dataset B, or both (where the choice depends on the inter-vendor collaboration Options (4-1 or 3a-1), the training alternatives (Alt 1 or Alt 2) within the Options, and the choice of target CSI for training)

Case 3 (for direction B): NW-side train an encoder-decoder on dataset A and transfers the encoder parameters to UE.
Study issue 4 and 6 by evaluating the inference performance for Case 2 / 3 on test dataset B, comparing to the inference performance for case 1 on test dataset B.
Note: Evaluations are assumed to perform without common reference model structure among companies.

R1-2409195 Updated summary of Evaluation Results for AI/ML CSI compression Moderator (Qualcomm)

From Friday session

Agreement

· For the evaluation study of offline engineering for Direction C for Issue 9:

o Case 1: The AI/ML model is trained based on training Dataset B, and then the AI/ML model performs inference/test on a dataset from test Dataset B.

§ Note: This serves as the upper-bound performance.

o Case 2: The AI/ML model is trained based on training Dataset S, and then the AI/ML model performs inference/test on test Dataset B.

§ Note: This represents the performance of Direction C when not using field data.

o Case 2A:

§ Step 1: The AI/ML model is trained based on training Dataset S

§ Step 2:

· NW-side and/or UE-side may separately train new CSI reconstruction part and/or CSI generation part compatible to the AI/ML model from Step 1 based on training Dataset B, as agreed in Note 1-1, 1-2, and 1-3 as agreed in RAN1#118.

· Dataset from Step 1 may be additionally used.

§ Step3: The CSI generation part and the CSI reconstruction part from Step 2 performs inference/test on test Dataset B

§ Note: This represents the performance of Direction C when the AI/ML models are updated based on field data.

o Note: Dataset S is meant to represent the synthetic data used for fully specified model development, and Dataset B is meant to represent the field data.

§ Examples for Dataset S and B:

· Modeling via TxRU mapping, UMi vs. UMa, UMa vs. InH, etc.

o It is acknowledged that the scenario/configuration modeling between S and B may not be complete representative of the difference between synthetic and field data distribution mismatch.

· Synthetic vs. actual field data (if available)

o Companies are encouraged to provide details on the scenarios/configurations underlying the field data

o Note: Case 1 and Case 2 have been studied during Rel-18 generalization study and conclusions have been captured in the TR.

o Note: For Case 2A, companies may additionally evaluate UE-side / NW-side data distribution mismatch with respect to UE side additional condition. This can be done, in Step 2, by treating the training Dataset B as representing UE-side data distribution and considering a training Dataset A representing NW-side data distribution.

o Note: Evaluations are assumed to perform without common reference model among companies.

Final summary in R1-2409161.

9.1.4.22 Other aspects of AI/ML model and data

Including model identification/procedure for two-sided model, collection of UE-sided model training data, and model transfer/delivery

R1-2407618 Discussion on other aspects of AI/ML model and data on AI/ML for NR air-interface FUTUREWEI

R1-2407657 Discussion on other aspects of the additional study for AI/ML Huawei, HiSilicon

R1-2407697 Discussion on other aspects of AI/ML model and data Spreadtrum Communications

R1-2407749 Other aspects of AI/ML model and data Tejas Network Limited

R1-2407800 Discussion on other aspects of AI/ML model and data ZTE Corporation, Sanechips

R1-2407852 Other aspects of AI/ML model and data vivo

R1-2407896 Discussion on other aspects of AI/ML model and data CMCC

R1-2407941 Discussions on other aspects of AlML In NR air interface TCL

R1-2407954 Further study on AI/ML model and data Xiaomi

R1-2407992 AI/ML Model and Data Google

R1-2408031 Study on AI/ML for other aspects CATT, CICTCI

R1-2408107 Discussion on other aspects of AI/ML model and data Fujitsu

R1-2408162 Additional study on other aspects of AI/ML model and data OPPO

R1-2408222 Discussion on other aspects of AI/ML model and data NEC

R1-2408269 Discussion on other aspects of AI/ML Ericsson

R1-2408292 Other aspects of AI/ML model and data Intel Corporation

R1-2408335 Discussion on other aspects of AI/ML model and data LG Electronics

R1-2408394 Additional study on other aspects of AI model and data NVIDIA

R1-2408432 Discussion on other aspects of AI/ML model and data Lenovo

R1-2408438 On other aspects of AI/ML model and data InterDigital, Inc.

R1-2408456 Discussion on other aspects of AI/ML model and data Apple

R1-2408541 Discussion on other aspects for AI/ML for air interface Panasonic

R1-2408548 Other aspects of AI/ML for two-sided model use case Nokia

R1-2408561 Discussion on other aspects of AI/ML model and data ETRI

R1-2408634 Views on additional study for other aspects of AI/ML model and data Samsung

R1-2408750 Other Aspects of AI/ML Model and Data Meta

R1-2408751 Discussion on other aspects of AI/ML model and data Sharp

R1-2408758 Other Aspects of AI/ML framework AT&T

R1-2408777 Discussion on other aspects of AI/ML model and data NTT DOCOMO, INC.

R1-2408841 Other aspects of AI/ML model and data Qualcomm Incorporated

R1-2408885 Other aspects of AI/ML model and data Continental Automotive

R1-2409168 Summary #1 for other aspects of AI/ML model and data Moderator (OPPO)

From Tuesday session

Agreement

Regarding model transfer/delivery Case z4 for inference, further study the following aspects:

Whether/when UE needs the transfer of new parameters for a known model structure.
Whether/when the AI model with the transferred parameters is ready for inference.
The transfer of partial of the parameters for a known model structure.

R1-2409169 Summary #2 for other aspects of AI/ML model and data Moderator (OPPO)

From Wednesday session

Agreement

Regarding the study of model transfer/delivery Case z4, for a given known model structure, network can transmit the following information along with the parameters:

a first indication referring to the known model structure at least for the case there are multiple known model structures
a second indication referring to the transmitted parameters
FFS: relationship of model ID, first indication, and second indication
FFS: transfer partial parameters

Conclusion

From RAN1 perspective, the model transfer/delivery Case z2 is deprioritized for two-sided model in Rel-19.

R1-2409170 Summary #3 for other aspects of AI/ML model and data Moderator (OPPO)

From Thursday session

Agreement

Regarding the study of MI-Option2 (i.e., model identification with dataset transfer) for the two-sided model, ID (denoted as ID-X) can be transmitted from network/network-side to UE/UE-side for the dataset.

· Note: The notation “ID-X” is used for discussion purpose

Final summary in R1-2409171.

RAN1#119

9.1 Artificial Intelligence (AI)/Machine Learning (ML) for NR Air Interface

Please refer to RP-242399 for detailed scope of the WI. Additional RAN guidance on Rel-18 AI/ML for NR Air Interface can be found in RP-242387.

R1-2410844 Session notes for 9.1 (AI/ML for NR Air Interface) Ad-Hoc Chair (CMCC)

Friday decision: The session notes are endorsed and contents reflected below.

[119-R19-AI/ML] – Taesang (Qualcomm)

Email discussion on Rel-19 AI/ML

- To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc

9.1.1 Specification support for beam management

R1-2409395 Discussion on AI/ML for beam management Huawei, HiSilicon

R1-2409447 Discussion on AI/ML for Beam Management Quectel

R1-2409455 Discussion on AI/ML for beam management InterDigital, Inc.

R1-2409479 Discussion on AI/ML-based beam management ZTE Corporation, Sanechips

R1-2409499 Discussion on specification support for beam management CMCC

R1-2409569 Specification Support for AI/ML for Beam Management Kyocera

R1-2409581 Discussion for supporting AI/ML based beam management Samsung

R1-2409625 Discussion on AIML for beam management Spreadtrum, UNISOC

R1-2409668 Specification support for beam management vivo

R1-2409741 Specification support for beam management Intel Corporation

R1-2409749 Specification support for beam management Tejas Networks Limited

R1-2409780 Specification support for AI-enabled beam management NVIDIA

R1-2409787 Discussion on AI/ML beam management Apple

R1-2409840 Discussion on specification support for beam management Ruijie Networks Co. Ltd

R1-2409855 Discussion on specification support for beam management NEC

R1-2409877 Discussion on AI/ML for beam management Xiaomi

R1-2409925 Specification support for AI/ML-based beam management CATT, CBN

R1-2409957 Discussion on specification support for beam management Panasonic

R1-2409960 Discussion on specification support for AI/ML beam management Transsion Holdings

R1-2409985 AI/ML for Beam Management Nokia

R1-2409994 Discussion on AI/ML for beam management China Telecom

R1-2410018 AI/ML specification support for beam management Lenovo

R1-2410029 Discussion on specification support for AI/ML-based beam management FUTUREWEI

R1-2410048 Discussion on specification support on AI/ML for beam management Fujitsu

R1-2410101 On specification for AI/ML-based beam management OPPO

R1-2410149 AI/ML based Beam Management Google

R1-2410174 Discussion on AI/ML for beam management HONOR

R1-2410185 FL plan for mobility enhancements in RAN1#119 Moderator (Fujitsu)

R1-2410193 Discussions on AI/ML for beam management LG Electronics

R1-2410204 Discussion on AIML beam management TCL Late submission

R1-2410216 Discussion on specification support for beam management Sony

R1-2410255 Specification support for beam management Fraunhofer HHI, Fraunhofer IIS

R1-2410257 Discussion on specification support for beam management ETRI

R1-2410344 Discussion on AI/ML based beam management KT Corp.

R1-2410347 AI/ML for Beam Management Meta

R1-2410354 AI/ML for beam management Ericsson

R1-2410359 Discussions on specification support for beam management Sharp

R1-2410367 Discussions on AI/ML for beam management CAICT

R1-2410373 Discussion on Specification Support of AI/ML for Beam Management Indian Institute of Tech (M), IIT Kanpur

R1-2410376 Discussion on AI/ML for beam management NTT DOCOMO, INC.

R1-2410466 Specification support for AI-ML-based beam management Qualcomm Incorporated

R1-2410504 Specification support for beam management KDDI Corporation

R1-2410519 Discussion on specification support for AIML-based beam management MediaTek Inc.

R1-2410547 Specification support for AI/ML beam management ITL

R1-2410587 On Associated ID for Beam Management Use Case NTU

R1-2410733 FL summary #0 for AI/ML in beam management Moderator (Samsung)

From Monday session

Agreement

For UE-sided model, at least for BM-Case 1, the beam information in inference result report is CRI/SSBRI of resource in Set A.

R1-2410734 FL summary #1 for AI/ML in beam management Moderator (Samsung)

From Tuesday session

Conclusion

For BM-Case 2 of UE-side model, only fixed Set B across different time instance is supported for single CSI report.

Agreement

For both BM-Case 1 and BM-Case 2, for UE-sided model for inference, when Set A and Set B are configured within CSI report configuration,

· two CSI-ResourceConfigId s are configured for Set A and Set B separately.

R1-2410735 FL summary #2 for AI/ML in beam management Moderator (Samsung)

Presented in Wednesday session.

R1-2410736 FL summary #3 for AI/ML in beam management Moderator (Samsung)

From Thursday session

Agreement

· In Step 3, following configurations are provided from NW to UE:

UE is allowed to do UAI reporting via OtherConfig,
The applicability report is based on A) and/or B)

It is up to RAN 2 to design the container
A) one or more of CSI-ReportConfig for inference configuration (wherein the associated ID may be configured in CSI framework as working assumption applied)

Note: CSI report configuration for UE-side model inference can’t be activated immediately upon receiving Step 3

B) One set or multiple sets of inference related parameters for applicability report only (not for inference)

It is up to RAN2 to design the container.
The set of inference related parameters selected from the IEs in/or the IEs referred by CSI-ReportConfig as a starting point, e.g.,

the associated ID

Note: this doesn’t imply the associated ID is mandatory

Set A related information
Set B related information
Report content related information
For BM-Case 2,

Time instances related information for measurements
Time instances related information for prediction

· In Step 4, UE reports applicability for all the above A) one or more CSI-ReportConfig and/or B) set(s) of inference related parameters

FFS on whether/what other information along with the applicability is needed
If A) is configured in Step 3,

Applicable aperiodic CSI Report and semi-persistent CSI report can be activated/triggered by NW after the applicability reported.
Applicable periodic CSI Report is considered as activated only if the applicability of the corresponding CSI-ReportConfig is reported in RRCReconfigurationComplete.

· In Step 5, NW can optionally configure CSI-ReportConfig for inference configuration in RRCReconfiguration, where the associated ID may be configured in CSI framework as working assumption applied.

Note: Step 5 may be optional if UE has already been configured with CSI-ReportConfig in Step 3

Agreement

At least for the monitoring Type 1 Option 2 of UE-side model monitoring (when applicable), support to reuse CSI framework for the configuration for monitoring result report in L1 signaling:

Dedicated resource set(s) for monitoring and report configuration for monitoring are configured in a dedicated CSI report configuration used for monitoring

o The ID of an inference report configuration is configured in the configuration for monitoring to link the inference report configuration and monitoring report configuration

FFS how to identify the connection between RSs in the resource set(s) for monitoring and Set A beams

FFS on whether to support all the combination on time domain behavior of the reportConfigType for infernece report and the reportConfigType for monitoring report
FFS on the timing related issues
UE measures the dedicated resource set(s) for monitoring.

R1-2410737 FL summary #4 for AI/ML in beam management Moderator (Samsung)

From Friday session

Conclusion

For the CSI-ReportConfig for inference configuration provided in Step 5,

· aperiodic CSI Report and semi-persistent CSI report can be activated/triggered by NW after RRCReconfigurationComplete.

· periodic CSI Report is considered as activated after RRCReconfigurationComplete.

· Note: UE is not expected to be configured with a CSI-ReportConfig for inference configuration for a non-applicable set of inference parameters or a non-applicable CSI-ReportConfig

o Any specification impact is a separate discussion

Agreement

Send LS to RAN2 with below information.

RAN1 thanks RAN2 for the LS on applicable functionality reporting for beam management UE-sided model.

In RAN1’s discussion of RAN 2 terminologies on beam management,

· The concept/terminology “functionality” of Supported functionalities may refer to UE-capability information/parameters i.e., Rel-19 AI/ML-enabled Features/FGs

· The concept/terminology “ functionality” of Applicable functionalities may refer to CSI-ReportConfig for inference configuration or a set of inference related parameters

· The Activated functionalities may be enabled based on CSI framework.

Therefore, the meaning and the granularity of “functionality” for Applicable functionalities, Activated functionalities and Supported functionalities may or may not be the same.

RAN 1 made the following agreements related to the Questions from RAN 2:

Agreement

• In Step 3, following configurations are provided from NW to UE:

o UE is allowed to do UAI reporting via OtherConfig,

o The applicability report is based on A) and/or B)

§ It is up to RAN 2 to design the container

§ A) one or more of CSI-ReportConfig for inference configuration (wherein the associated ID may be configured in CSI framework as working assumption applied)

· Note: CSI report configuration for UE-side model inference can’t be activated immediately upon receiving Step 3

§ B) One set or multiple sets of inference related parameters for applicability report only (not for inference)

· It is up to RAN2 to design the container.

· The set of inference related parameters selected from the IEs in/or the IEs referred by CSI-ReportConfig as a starting point, e.g.,

o the associated ID

§ Note: this doesn’t imply the associated ID is mandatory

o Set A related information

o Set B related information

o Report content related information

o For BM-Case 2,

§ Time instances related information for measurements

§ Time instances related information for prediction

• In Step 4, UE reports applicability for all the above A) one or more CSI-ReportConfig and/or B) set(s) of inference related parameters

o FFS on whether/what other information along with the applicability is needed

o If A) is configured in Step 3,

§ Applicable aperiodic CSI Report and semi-persistent CSI report can be activated/triggered by NW after the applicability reported.

§ Applicable periodic CSI Report is considered as activated only if the applicability of the corresponding CSI-ReportConfig is reported in RRCReconfigurationComplete.

• In Step 5, NW can optionally configure CSI-ReportConfig for inference configuration in RRCReconfiguration, where the associated ID may be configured in CSI framework as working assumption applied.

o Note: Step 5 may be optional if UE has already been configured with CSI-ReportConfig in Step 3

Agreement

For beam management, multiple CSI reports for inference for UE-side model can be configured/activated/triggered, which is up to UE capability.

Conclusion

For the CSI-ReportConfig for inference configuration provided in Step 5,

· aperiodic CSI Report and semi-persistent CSI report can be activated/triggered by NW after RRCReconfigurationComplete.

· periodic CSI Report is considered as activated after RRCReconfigurationComplete.

· Note: UE is not expected to be configured with a CSI-ReportConfig for inference configuration for a non-applicable set of inference parameters or a non-applicable CSI-ReportConfig

o Any specification impact is a separate discussion

RAN1 would like to provide replies on the following questions from RAN2 in R2-2407848:

Q1: In Step 2, what is the granularity of functionality? For example, whether it is a use case (e.g. beam management), whether it is a sub-use case (e.g. beam management Case 1), or others?

Answer to Q1: In Step 2, RAN1 expects that UE reports its UE-capability information/parameters, i.e., Rel-19 AI/ML-enabled Features/FGs (including components and corresponding value ranges). These UE capability information/parameters will depend on how FGs are defined including the granularity, that will be discussed in RAN1 later in the WI.

Q2: What is the content of NW-side additional condition, i.e. is it correct the RAN2 assumption of a NW-side additional condition assumed as associated ID?

Answer to Q2: RAN 1 did not have agreement on the content of NW-side additional condition. RAN1 agreed to support associated ID and it can be used to ensure the consistency of NW-side additional condition across training and inference for UE-sided model for BM-Case 1 and BM Case 2. UE may assume the similar properties of a DL Tx beam or beam set/list associated with the same associated ID, while FFS whether/how to define similar properties of a DL Tx beam or beam set/list.

Q3: Is NW-side additional condition functionality specific?

Answer to Q3: Please also refer to the answer to Q2 to understand the ongoing discussion about the associated ID for NW-side additional condition. And please refer to the agreements related to the Questions from RAN 2.

Q4: RAN2 wonders what information is needed in Step 3 for UE to decide whether a functionality is applicable before Step 4. More specifically, RAN2 would like to ask the following questions (Q4-1 to Q4-5):

Answer to Q4: And please refer to the agreements related to the Questions from RAN 2.

Q4-1: In RAN2, it is FFS whether NW-side additional condition is mandatory or optional. In order to discuss further, RAN2 would like to understand whether it is feasible for UE to decide the applicable functionalities without NW-side additional condition?

Answer to Q4-1: There is no consensus yet on whether it is mandatory or optional. There is no conclusion yet on whether it is feasible or not for UE to decide the applicability without NW-side additional condition, and RAN 1 is discussing the related issues.

Q4-2: In RAN2, it is FFS whether configuration (e.g. inference configuration) other than NW-side additional condition can be included in Step 3. RAN2 would like to understand whether it is feasible and required for gNB to provide configuration (e.g. inference configuration) other than NW-side additional condition in Step 3 for UE to determine applicable functionalities?

Answer to Q4-2: Please refer to the agreements related to the Questions from RAN 2.

Q4-3: For UE evaluating applicable functionality reporting, if the answer to Q4-2 is Yes, what is the relationship between NW-side additional condition and configuration (e.g. inference configuration)? For example, is NW-side additional condition part of inference configuration, or is inference configuration part of NW-side additional condition, or is NW-side additional condition separate from inference configuration, etc?

Answer to Q4-3: Please refer to the agreements related to the Questions from RAN 2.

Q4-4: If the answer to Q4-2 is Yes, what is the content of configuration (e.g. inference configuration) for UE to determine applicable functionalities?

Answer to Q4-4: Please refer to the agreements related to the Questions from RAN 2.

Q5: What is the content of applicable functionality reporting in Step 4?

Answer to Q5: Please refer to the agreements related to the Questions from RAN 2.

Q6: What is the content of inference configuration in Step 5?

Answer to Q6: Please refer to the agreements related to the Questions from RAN 2. The content of inference configuration as CSI-ReportConfig is to be designed later in RAN1.

Q7: If inference configuration is provided in Step 3, does it activate the functionality immediately upon receiving Step 3?

Answer to Q7: Please refer to the agreements related to the Questions from RAN 2.

Q8: If inference configuration is not provided in Step 3, does configuration in Step 5 activate the functionality immediately upon receiving Step 5?

Answer to Q8: Please refer to the agreements/conclusion related to the Questions from RAN 2.

Q9: If more than one functionality are configured in Step 3 or Step 5, whether multiple/all applicable functionalities can be activated?

Answer to Q9: Please refer to the agreements related to the Questions from RAN 2.

Q10: Is L1/L2 signaling for functionality activation/deactivation needed?

Answer to Q10: Please refer to the agreements related to the Questions from RAN 2. With that, RAN1 understands that L1 and MAC signalling can be used for aperiodic CSI Report and semi-persistent CSI report.

R1-2410893 [DRAFT] Reply LS on applicable functionality reporting for beam management UE-sided model Samsung

Decision: The draft LS is endorsed. Final reply LS is approved in R1-2410898.

Final summary in R1-2410892.

9.1.2 Specification support for positioning accuracy enhancement

R1-2409396 Discussion on AI/ML for positioning accuracy enhancement Huawei, HiSilicon

R1-2409443 AI/ML for Positioning Accuracy Enhancement Ericsson

R1-2409480 Discussion on AI/ML-based positioning enhancement ZTE Corporation, Pengcheng Laboratory

R1-2409500 Discussion on specification support for positioning accuracy enhancement CMCC

R1-2409543 Discussion on AI/ML for positioning accuracy enhancement New H3C Technologies Co., Ltd.

R1-2409582 Discussion for supporting AI/ML based positioning accuracy enhancement Samsung

R1-2409669 Specification support for positioning accuracy enhancement vivo

R1-2409742 Specification support for positioning accuracy enhancement Intel Corporation

R1-2409750 Specification support for positioning accuracy enhancement Tejas Networks Limited

R1-2409781 Specification support for AI-enabled positioning NVIDIA

R1-2409788 Discussion on Specification Support for AI/ML-based positioning Apple

R1-2409841 Discussion on specification support for positioning accuracy enhancement Ruijie Networks Co. Ltd

R1-2409845 Discussion on support for AIML positioning InterDigital, Inc.

R1-2409852 Discussion on specification support for AIML based positioning accuracy enhancement NEC

R1-2409878 Discussion on AI/ML-based positioning accuracy enhancement Xiaomi

R1-2409926 Specification support for AI/ML-based positioning CATT, CICTCI

R1-2409986 AI/ML for Positioning Accuracy Enhancement Nokia

R1-2410019 Specification impacts for AI/ML positioning Lenovo

R1-2410049 Discussion on specification support for AIML-based positioning accuracy enhancement Fujitsu

R1-2410102 On specification for AI/ML-based positioning accuracy enhancements OPPO

R1-2410150 AI/ML based Positioning Google

R1-2410205 AI/ML positioning accuracy enhancement Fraunhofer IIS, Fraunhofer HHI

R1-2410215 Discussion on specification support for positioning accuracy enhancement TCL

R1-2410217 Support for AI/ML for positioning accuracy enhancement Sony

R1-2410258 Discussion on specification support for positioning accuracy enhancement ETRI

R1-2410360 Discussion on specification support for AI/ML based positioning accuracy enhancements Sharp

R1-2410377 Discussion on AI/ML for positioning accuracy enhancement NTT DOCOMO, INC.

R1-2410414 Discussion on specification support for AI-ML based positioning accuracy enhancement Baicells

R1-2410424 Specification Support of AI/ML for Positioning Accuracy Enhancement Indian Institute of Tech (M), IIT Kanpur

R1-2410467 Specification support for AI-ML-based positioning accuracy enhancement Qualcomm Incorporated

R1-2410531 Design for AI/ML based positioning MediaTek Korea Inc.

R1-2410571 Discussion on specification support for AI/ML Positioning Accuracy enhancement CEWiT

R1-2410588 Discussions on specification support for positioning accuracy enhancement for AI/ML ITL

R1-2410714 Summary #1 of specification support for positioning accuracy enhancement Moderator (Ericsson)

From Monday session

Conclusion

For measurement report of AI/ML assisted positioning Case 3a, regarding the report of LOS/NLOS indicator,

· LOS/NLOS indicator can’t be reported independently from other measurements

R1-2410715 Summary #2 of specification support for positioning accuracy enhancement Moderator (Ericsson)

From Tuesday session

Agreement

For the definition of sample-based measurement, for gNB/TRP measurement of an estimated channel response between a pair of UE and TRP, the starting time of the list of N_t consecutive samples is determined as follows.

· starting time = first detected path rounded down with timing granularity T.

Note: UE-side measurement is a separate discussion.

R1-2410716 Summary #3 of specification support for positioning accuracy enhancement Moderator (Ericsson)

From Wednesday session

Agreement

For model performance monitoring of AI/ML positioning Case 1, support at least:

· Option A. The target UE side performs monitoring metric calculation.

o The target UE may signal the monitoring outcome to the LMF.

o FFS: content of monitoring outcome

· FFS: Option B

R1-2410717 Summary #4 of specification support for positioning accuracy enhancement Moderator (Ericsson)

Presented in Thursday session.

R1-2410718 Summary #5 of specification support for positioning accuracy enhancement Moderator (Ericsson)

From Friday session

Agreement

For Rel-19 AI/ML based positioning, for Case 3b, in addition to path-based measurement that is referring to the measurement in the existing specifications (up to Rel-18), additionally support the following enhancement to the measurement,

The measurement is composed of N_t' values of the estimated channel response in time domain. The N_t’ values are selected from a list of N_t consecutive channel response values, which have timing granularity T.
The timing information for the N_t' values are reported with a timing granularity T, where T=2^kxT_c. k represents the timing reporting granularity factor. T_c is the basic time unit for NR.

The associated measurement (e.g., power if reported) corresponds to the measurement for the reported N_t' values.

The timing information is defined relative to a reference time, same as the path-based measurement.
The N_t’ selected time domain channel measurement values are expected to be those with the highest power.
The starting time of the list of N_t consecutive values is determined as: starting time = first detected path rounded down with timing granularity T.
LMF can signal parameter values of N_t, N_t', k to gNB via NRPPa. Candidate set values:

N_t'<=24. FFS: N_t' values.
N_t = {32, 64, 128}
FFS: k
The gNB/TRP may use different N_t', N_t and/or k values other than the signalled parameter for measurement reporting. In this case, it’s up to LMF implementation to process the reported measurement

· FFS: whether transmit offset from gNB to LMF

Note: measurement by UE is a separate discussion.

Note: the purpose of the time domain channel measurements, such as for Rel-19 AI/ML based positioning, is not specified

Agreement

For AI/ML based positioning Case 1, all assistance information from legacy UE-based DL-TDOA, other than info #7, can be provided from LMF to UE. For info #7, RAN1 study, if necessary, choose one alternative from the following:

Alternative 1. Info #7 is provided implicitly via associated ID.

Associated ID is signaled by LMF to indicate whether info #7 is consistent between training and inference.

Alternative 2. Info #7 can be provided either implicitly or explicitly by LMF. Note: no UE capability is introduced on whether info #7 is provided implicitly or explicitly, and the UE can request info #7 to be provided explicitly or implicitly.

If provided implicitly, associated ID is signaled by LMF to indicate whether info #7 is consistent between training and inference.

Alternative 3. Info #7 is not be provided from LMF to UE.

If info #7 is not provided, UE may assume info #7 is consistent between training and inference.

Alternative 4. Info #7 is provided explicitly from LMF to UE.

7	Geographical coordinates of the TRPs served by the gNB (include a transmission reference location for each DL-PRS Resource ID, reference location for the transmitting antenna of the reference TRP, relative locations for transmitting antennas of other TRPs)

Final summary in R1-2410921.

9.1.3 Specification support for CSI prediction

Discussions on RAN1#118bis and RAN1#119 will be limited to the study on consistency of training/inference.

R1-2410654 Discussion on AI/ML for CSI prediction Huawei, HiSilicon (rev of R1-2409397)

R1-2409449 AI/ML for CSI prediction Ericsson

R1-2409481 Discussion on specification support for AI CSI prediction ZTE Corporation, Sanechips

R1-2409501 Discussion on AI/ML for CSI prediction CMCC

R1-2409583 Views on AI/ML based CSI prediction Samsung

R1-2409626 Discussion on AIML for CSI prediction Spreadtrum, UNISOC

R1-2410673 Study on consistency issue for CSI prediction vivo (rev of R1-2409670)

R1-2409751 Discussion on study for AI/ML CSI prediction Tejas Networks Limited

R1-2409782 Specification support for AI-enabled CSI prediction NVIDIA

R1-2409789 Discussion on AI/ML-based CSI prediciton Apple

R1-2409853 Discussion on specification support for CSI prediction NEC

R1-2409879 Discussion on AI/ML model based CSI prediction Xiaomi

R1-2409927 Specification support for AI/ML-based CSI prediction CATT

R1-2409987 AI/ML for CSI Prediction Nokia

R1-2409995 Discussion on AI/ML for CSI prediction China Telecom

R1-2410020 On AI/ML for CSI prediction Lenovo

R1-2410042 On AI/ML-based CSI prediction InterDigital, Inc.

R1-2410050 Discussion on specification support for CSI prediction Fujitsu

R1-2410103 On specification for AI/ML-based CSI prediction OPPO

R1-2410151 AI/ML based CSI Prediction Google

R1-2410194 Discussions on CSI prediction LG Electronics

R1-2410218 Further views on consistency issues in CSI prediction Sony

R1-2410248 Discussion on consistency of training / inference for AI/ML-based CSI prediction Panasonic

R1-2410259 Discussion on specification support for CSI prediction ETRI

R1-2410336 Discussion on AI/ML for CSI prediction AT&T

R1-2410378 Discussion on AI/ML for CSI prediction NTT DOCOMO, INC.

R1-2410468 Specification support for CSI prediction Qualcomm Incorporated

R1-2410537 AI/ML - Specification support for CSI Prediction MediaTek Inc.

R1-2410564 AI/ML for CSI prediction Mavenir

R1-2410817 Summary #1 of CSI prediction Moderator (LG Electronics)

Presented in Wednesday session.

R1-2410818 Summary #2 of CSI prediction Moderator (LG Electronics)

Presented in Thursday session.

Final summary in R1-2410899.

9.1.4 Additional study on AI/ML for NR air interface

9.1.4.1 CSI compression

R1-2409398 Discussion on AI/ML for CSI compression Huawei, HiSilicon

R1-2409450 AI/ML for CSI compression Ericsson

R1-2409482 Discussion on study for AI/ML CSI compression ZTE Corporation, Sanechips

R1-2409502 Discussion on AI/ML for CSI compression CMCC

R1-2409584 Views on additional study for AI/ML based CSI compression Samsung

R1-2409627 Discussion on AIML for CSI compression Spreadtrum, UNISOC

R1-2409671 Discussion on CSI compression vivo

R1-2409743 AI/ML for CSI compression Intel Corporation

R1-2409752 Discussion on AI/ML for CSI Compression Tejas Networks Limited

R1-2409783 Additional study on AI-enabled CSI compression NVIDIA

R1-2409790 Discussion on AI based CSI compression Apple

R1-2409854 Discussion on CSI compression NEC

R1-2409880 Views on AI/ML model based CSI compression Xiaomi

R1-2409928 Additional study on AI/ML-based CSI compression CATT

R1-2409988 AI/ML for CSI Compression Nokia

R1-2410021 On AI/ML for CSI compression Lenovo

R1-2410030 Discussion of CSI compression on AI/ML for NR air interface FUTUREWEI

R1-2410043 On AI/ML-based CSI compression InterDigital, Inc.

R1-2410051 Discussion on CSI compression with AI/ML Fujitsu

R1-2410104 Additional study on AI/ML-based CSI compression OPPO

R1-2410152 AI/ML based CSI Compression Google

R1-2410195 Study on CSI compression LG Electronics

R1-2410201 Discussion on AI/ML for CSI compression KAIST

R1-2410202 Discussion on AIML CSI compression TCL Late submission

R1-2410249 Discussion on AI/ML for CSI compression Panasonic

R1-2410260 Discussion on AI/ML for CSI compression ETRI

R1-2410379 Discussion on AI/ML for CSI compression NTT DOCOMO, INC.

R1-2410425 Discussion and evaluation results on AI/ML for CSI Compression Indian Institute of Tech (M), IIT Kanpur

R1-2410469 Additional study on CSI compression Qualcomm Incorporated

R1-2410508 Additional study on AI/ML for NR air interface - CSI compression MediaTek Inc.

R1-2410572 Discussion on AI/ML for CSI compression CEWiT

R1-2410589 Discussion an AI/ML based CSI Compression IIT Kanpur, Indian Institute of Tech (M)

R1-2410719 Summary#1 of Additional study on AI/ML for NR air interface: CSI compression Moderator (Qualcomm)

From Tuesday session

Conclusion

For Direction A 4-1 and 3a-1, send LS to RAN2 for the study of feasibility of parameter / dataset exchange

Wednesday further clarification regarding above LS, additionally CC SA2, SA3, SA5.

Note: Samsung denies CC.

R1-2410720 Summary#2 of Additional study on AI/ML for NR air interface: CSI compression Moderator (Qualcomm)

From Tuesday session

Agreement

For Direction A Option 3a-1 and Direction C, study the feasibility of scalable model structure specification over numbers of Tx ports, CSI feedback payload sizes, and bandwidths, number of slots.

Feasibility of Direction A Option 3a-1 is contingent on the feasibility of the scalable model structure specification.
Feasibility of Direction C is contingent on the feasibility of the scalable model structure specification and model parameters specification.
Note: Angular/Delay/Doppler domain conversion and quantization are considered to be part of feasibility study

Agreement

For studying the standardized model structure,

For temporal domain Case 0,

In case of spatial-frequency domain input, adopt Transformer as the backbone structure.
Further study angular-frequency and angular-delay domain input

For temporal domain Case 2,

In case of spatial-frequency domain input, take into account the model structure of Case 0 with an adaptation. Study the following options for the adaptation:

Option 1: Input/output adaptation with additional layers

Conv-LSTM
LSTM

Option 2: Latent adaptation on top of Case 0 model structure

Reusing Case 0 structure and changing quantization operation and/or feedback payload over different slots

Note: other options are not precluded

Further study angular-frequency and angular-delay domain input

For temporal domain Case 3,

In case of spatial-frequency domain input, take into account the model structure of Case 0 with an adaptation. Study the following options for the adaptation:

Option 1: Input/output adaptation
Option 2: Latent adaptation

Further study angular-frequency, angular-delay, and angular-delay-Doppler domain input.

Take precoding matrix in the spatial-frequency domain in a subband granularity as the input, and the reconstructed precoding matrix in the spatial-frequency as the output, for the study of standardized model structure.

Note: Processing steps at the UE to derive angular, delay, and/or Doppler domain basis, and corresponding reconstruction steps at the gNB are considered.
Note: scalar/vector quantization and dequantization are considered. Quantization-aware training with jointly updated quantization method/parameters (Case 2-2) is used.

R1-2410721 Summary#3 of Additional study on AI/ML for NR air interface: CSI compression Moderator (Qualcomm)

Presented in Wednesday session.

R1-2410722 Summary#4 of Additional study on AI/ML for NR air interface: CSI compression Moderator (Qualcomm)

From Thursday session

Agreement

For NW to collect data for training, study following spec impacts

· Data format: codebook-based Rel-16 eType2 or Rel-18 eType2 for PMI prediction.

o FFS if enhancement is needed

o FFS number of samples in the report.

o FFS whether channel or precoder is needed for temporal Cases 3

· Configuration of rank/layer, number of subbands

· Mechanism for ground-truth reporting

· FFS: Report additional information regarding the samples, e.g., data quality, FFS the definition of data quality and corresponding parameters.

· FFS if enhancements in CSI-RS and SRS configuration is needed.

· FFS: Report associated information that captures UE side additional condition

· FFS: Configuration / reporting of temporal aspects for temporal Case 2 and Case 3, e.g., association between input and output CSI

· FFS: details of CSI measurement

For UE to collect data for training, study following spec impacts

· NW configuration or UE request, e.g., RS configuration/transmission for data collection

· Whether enhancements in CSI-RS configuration is needed.

· Configuration of temporal aspects for temporal case 2/3, e.g., association between input and output CSI

· FFS: Need of configuration of ID, and configuration of ID.

R1-2410723 Summary#5 of Additional study on AI/ML for NR air interface: CSI compression Moderator (Qualcomm)

From Friday session

R1-2410725 Updated summary of Evaluation Results for AI/ML CSI compression Moderator (Qualcomm)

Agreement

To capture all observations in section 2 of R1-2410725 to TR38.843.

R1-2410915 [Draft] LS on signalling feasibility of dataset and parameter sharing Qualcomm

Agreement

Draft LS R1-2410915 with the following updates:

1- Revising “The size becomes 600K * (2000 bits) / (8bits/Byte) = 150 MB+ 11.6 MB = 161.6MB if we assume N1=N2.” To “The size becomes N2 * (2000 bits) / (8bits/Byte) + 11.6 MB” , and

2- Revising

Action: RAN1 respectfully asks RAN2’s feedback on the feasibility of standardized signaling (over-the-air and/or other approaches) for

· Dataset sharing consisting of {(Target CSI, CSI feedback)}

· Encoder parameter sharing

· Encoder parameter sharing + dataset sharing consisting of {target CSI}

Action: RAN1 respectfully asks RAN2’s feedback on the feasibility of standardized signaling (over-the-air and/or other approaches) for NW-side sharing model parameters and/or dataset to the UE or UE-side for the following options

· Dataset sharing consisting of {(Target CSI, CSI feedback)}

· Encoder parameter sharing

· Encoder parameter sharing + dataset sharing consisting of {target CSI}

3- Deleting

“RAN1 respectfully requests RAN2’s feedback on the feasibility of standardized signaling, considering the size of dataset / encoder parameters provided above.”

4- Deleting

“The size is based on Case 0 of two-sided CSI compression; the size may or may not be larger for Case 2 and Case 3.” from “For Option 4-1: sharing {target CSI, CSI feedback} dataset:”

Final LS is approved in

R1-2410922 LS on signalling feasibility of dataset and parameter sharing RAN1, Qualcomm

Agreement

For temporal domain aspects Case 3, study LCM aspects and specification impacts,

consider the following options for training data collection

· Option 1: The target CSI for training is derived based on the predicted CSI of the future slot(s).

· Option 2: The target CSI for training is derived based on the measured CSI of the future slot(s).

· Note: During inference, the input to the CSI generation part is derived based on the predicted CSI.

consider following options for the monitoring labels

· Option 1: The monitoring label is derived based on the predicted CSI of the future slot(s).

o CSI prediction output is used as input to CSI generation part.

o Note: This corresponds to monitoring of CSI compression only. CSI prediction may be monitored separately.

· Option 2: The monitoring label is derived based on the measured CSI of the future slot(s)

o Option 2a: CSI prediction output is used as input to CSI generation part.

§ Note: This corresponds to end-to-end monitoring of CSI prediction and compression.

o Option 2b: Measured CSI of the future slot(s) is used as input to CSI generation part for monitoring purpose.

§ Note: This corresponds to monitoring of CSI compression only. CSI prediction may be monitored separately.

Study how the functionality/model control (activation, deactivation, switching, and fallback) for CSI prediction and CSI compression interacts.

Final summary in R1-2410724.

9.1.4.22 Other aspects of AI/ML model and data

Including model identification/procedure for two-sided model, collection of UE-sided model training data, and model transfer/delivery

R1-2409399 Discussion on other aspects of the additional study for AI/ML Huawei, HiSilicon

R1-2409483 Discussion on other aspects of AI/ML model and data ZTE Corporation, Sanechips

R1-2409503 Discussion on other aspects of AI/ML model and data CMCC

R1-2409585 Views on additional study for other aspects of AI/ML model and data Samsung

R1-2409628 Discussion on other aspects of AI/ML model and data Spreadtrum, UNISOC

R1-2409672 Other aspects of AI/ML model and data vivo

R1-2409731 Discussion on other aspects of AI/ML Ericsson

R1-2409744 Other aspects of AI/ML model and data Intel Corporation

R1-2409753 Discussion on Other aspects of AI/ML model and data Tejas Networks Limited

R1-2409784 Additional study on other aspects of AI model and data NVIDIA

R1-2409791 Discussion on other aspects of AI/ML model and data Apple

R1-2409856 Discussion on other aspects of AI/ML model and data NEC

R1-2409881 Further study on AI/ML model and data Xiaomi

R1-2409929 Additional study on AI/ML for other aspects CATT, CICTCI

R1-2409989 Other aspects of AI/ML for two-sided model Nokia

R1-2409996 Discussion on other aspects of AI ML model and data China Telecom

R1-2410022 Discussion on other aspects of AI/ML model and data Lenovo

R1-2410031 Discussion on other aspects of AI/ML model and data on AI/ML for NR air-interface FUTUREWEI

R1-2410044 On other aspects of AI/ML model and data InterDigital, Inc.

R1-2410052 Discussion on other aspects of AI/ML model and data Fujitsu

R1-2410105 Additional study on other aspects of AI/ML model and data OPPO

R1-2410153 AI/ML Model and Data Google

R1-2410173 Discussion on other aspects for AI/ML for air interface Panasonic

R1-2410192 Other aspects of AI/ML model and data Continental Automotive

R1-2410196 Discussion on other aspects of AI/ML model and data LG Electronics

R1-2410203 Discussions on other aspects of AlML In NR air interface TCL Late submission

R1-2410261 Discussion on other aspects of AI/ML model and data ETRI

R1-2410335 Other Aspects of AI/ML framework AT&T

R1-2410380 Discussion on other aspects of AI/ML model and data NTT DOCOMO, INC.

R1-2410426 Discussion on other aspects of AI/ML model and data Sharp

R1-2410470 Other aspects of AI/ML model and data Qualcomm Incorporated

R1-2410775 Summary #1 for other aspects of AI/ML model and data Moderator (OPPO)

From Wednesday session

Agreement

For study of MI-Option2 (i.e., model identification with dataset transfer) for the two-sided model,

ID-X can be used for pairing the UE-part and the NW-part of a two-sided model
FFS: other information needed for pairing

Agreement

Regarding the relationship of model ID, first indication, and second indication for model transfer/delivery Case z4, further study the following options:

Opt.1: model ID consists of the information of the first indication and the second indication

E.g., model ID is a combination of the first and second indications

Opt.2: The second indication is assumed as the model ID
Opt.3: Model ID is assigned by network and is separated from the first indication and the second indication

Conclusion

Regarding MI-Option2 (i.e., model identification with dataset transfer) for the two-sided model, from RAN1 perspective, how to construct the dataset, including whether a dataset constructed from one cell or from multiple cells is up to network implementation.

R1-2410776 Summary #2 for other aspects of AI/ML model and data Moderator (OPPO)

From Thursday session

Conclusion

For the study of model delivery/transfer Case z4, if the model delivery/transfer is directly used for inference, the following options are identified as the candidate solutions to determine the readiness of AI model with the transferred parameters for inference (either or combination of the following options)

Option 1: UE sends signaling to network to notify that the AI model with the transferred parameters is ready for activation
Option 2: The AI model with the transferred parameters can be assumed ready for activation from a minimum applicable time after the completion of model delivery/transfer

R1-2410777 Summary #3 for other aspects of AI/ML model and data Moderator (OPPO)

Final summary in R1-2410778.

RAN1#120

9.1 Artificial Intelligence (AI)/Machine Learning (ML) for NR Air Interface

Please refer to RP-243244 for detailed scope of the WI.

Rapporteur to provide initial input on higher layer signalling under agenda item 9.1. For input on higher layer signalling from any other source, please include it as part of your tdoc to relevant sub-agenda items.

R1-2501546 Session notes for 9.1 (AI/ML for NR Air Interface) Ad-Hoc Chair (CMCC)

Friday decision: The session notes are endorsed and contents reflected below.

[120-R19-AI/ML] – Taesang (Qualcomm)

Email discussion on Rel-19 AI/ML

- To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc

R1-2501143 Rapporteur view on higher layer signalling of Rel-19 AI-ML for NR air interface Qualcomm Incorporated

9.1.1 Specification support for beam management

R1-2500050 Discussion on specification support for AI/ML-based beam management FUTUREWEI

R1-2500066 Discussion on AI/ML-based beam management ZTE Corporation, Sanechips

R1-2500089 Discussion on AI/ML for beam management Huawei, HiSilicon

R1-2500159 Discussion on AIML for beam management Spreadtrum, UNISOC

R1-2500201 Discussion on AI/ML-based beam management CATT

R1-2500254 Discussion on AI/ML for beam management China Telecom

R1-2500274 Discussion on specification support for beam management CMCC

R1-2500337 Specification support for beam management vivo

R1-2500390 Specification Support for AI/ML for Beam Management Kyocera

R1-2500391 AI/ML for beam management Ericsson

R1-2500404 Specification support for beam management Tejas Networks Limited

R1-2500465 On specification for AI/ML-based beam management OPPO

R1-2500512 Discussion on AI/ML for beam management Ofinno

R1-2500529 Discussion on AI/ML for beam management InterDigital, Inc.

R1-2500545 AI/ML based Beam Management Google

R1-2500555 Discussion on AIML beam management TCL

R1-2500560 Discussion on specification support for beam management Panasonic

R1-2500565 Discussions on AI/ML for beam management LG Electronics

R1-2500590 Discussion on specification support for beam management NEC

R1-2500635 AI/ML specification support for beam management Lenovo

R1-2500642 Discussion on Specification Support for Beam Management Sony

R1-2500669 Discussion on specification support for beam management Ruijie Networks Co. Ltd

R1-2500686 Specification support for AI-enabled beam management NVIDIA

R1-2500710 Discussion on AI/ML for beam management Xiaomi

R1-2500766 Enhancements for AI/ML enabled beam management Apple

R1-2500834 Discussion for supporting AI/ML based beam management Samsung

R1-2500877 Specification support for beam management KDDI Corporation

R1-2500900 Discussion on specification support for beam management ETRI

R1-2500925 Discussion on specification support on AI/ML for beam management Fujitsu

R1-2500962 Discussion on specification support for AI/ML beam management Transsion Holdings

R1-2500970 AI/ML for Beam Management Nokia

R1-2501013 Discussion on specification support for AIML-based beam management MediaTek Inc.

R1-2501085 AI/ML for Beam Management Meta

R1-2501103 Specification support for beam management Intel Corporation

R1-2501104 Discussion on AI/ML for beam management HONOR

R1-2501130 Discussions on specification support for beam management Sharp

R1-2501144 Specification support for AI-ML-based beam management Qualcomm Incorporated

R1-2501190 Discussion on AI/ML for beam management NTT DOCOMO, INC.

R1-2501226 Discussion on AI/ML based beam management KT Corp.

R1-2501235 Discussion on AIML based beam management ASUSTeK

R1-2501262 Discussions on AI/ML for beam management CAICT

R1-2501270 Specification support for beam management Fraunhofer HHI, Fraunhofer IIS

R1-2501333 Specification support for AI/ML beam management ITL

R1-2501440 FL summary #1 for AI/ML in beam management Moderator (Samsung)

From Monday session

Agreement

For report content of inference results for UE-sided model, where the largest RSRP value is quantized to a 7-bit value in the range [-140, -44] dBm with 1dB step size, and the differential RSRP is quantized to a 4-bit value with 2 dB step size.

Note: the model output is UE implementation and it doesn’t have to be RSRP subject to dBm value.

Agreement

For report content of inference results for UE-sided model for BM-Case 1, the RSRP of predicted beam(s)in the report of inference results, is the predicted RSRP, where the predicted RSRP is based on AI/ML output.

Note: how to capture it in the spec is a separate discussion.

R1-2501441 FL summary #2 for AI/ML in beam management Moderator (Samsung)

From Tuesday session

Agreement

For UE-side AI/ML model inference and BM-Case2, for the quantization of a RSRP value of inference results in a report over multiple future time instances,

· the largest RSRP value based on prediction of all time instances is the reference RSRP, and differential RSRPs in the report are computed relative to the reference RSRP.

o The time instance information of the beam with the largest RSRP are additionally indicated in the report.

R1-2501442 FL summary #3 for AI/ML in beam management Moderator (Samsung)

From Wednesday session

Agreement

For inference, for BM-Case 2 of UE-side model,

The time gap between two consecutive future time instances is configured by RRC, and the number of future time instance(s) N is configured by RRC.

time gap is [10ms, 20ms, 40ms, 80ms, 160ms]
N = [1, 2, 4, 8]

Reference time of the earliest time instance for the predicted results is based on the most recent occasion of the CSI-RS/SSB resource in Set B for measurement

Where the most recent occasion of the CSI-RS/SSB resource of set B is the latest CSI-RS/SSB occasion no later than the corresponding CSI reference resource of the corresponding inference report.

R1-2501443 FL summary #4 for AI/ML in beam management Moderator (Samsung)

Presented in Thursday session

R1-2501594 FL summary #5 for AI/ML in beam management Moderator (Samsung)

From Friday session

Agreement

For UE-sided model, for configuring the resource for data collection purpose, support

CSI-ReportConfig can used for configuring the resources for data collection purpose without CSI report.

One CSI-ResourceConfigId is configured for Set A.
One CSI-ResourceConfigId is configured for Set B.
Note: UE performs measurement on all resources
One or two associated IDs can be configured in CSI-ReportConfig

§ When Set B is equal or a subset of set A (i.e., NZP-CSI-RS-ResourceId/SSB-Index in the resource set for Set B is within the NZP-CSI-RS-ResourceId/SSB-Index in the resource set for Set A), one associated ID is configured,

§ Otherwise, one associated ID is configured for Set A and another one associated ID is configured for Set B

FFS: whether/how to support 'aperiodic' CSI RS

Note: This is not related to whether/how to support delivery/transmission of the collected data for training for UE-sided model.

Agreement

For UE-sided model, in CSI-ReportConfig for inference

One or two associated IDs can be configured in CSI-ReportConfig

o When Set B is equal or a subset of set A (i.e., NZP-CSI-RS-ResourceId/SSB-Index in the resource set for Set B is within the NZP-CSI-RS-ResourceId/SSB-Index in the resource set for Set A), one associated ID is configured,

o Otherwise, one associated ID is configured for Set A and another one associated ID is configured for Set B

FFS: At least BM-Case 1, the applicability for 'aperiodic' CSI RS

Final summary in R1-2501595.

9.1.2 Specification support for positioning accuracy enhancement

From AI5

R1-2500388 LS on LMF-based AI/ML Positioning for Case 2b SA2, vivo

R1-2500389 LS on LMF-based AI/ML Positioning for case 3b SA2, Ericsson

Decision:SA2 (in R1-2500388) is requesting RAN1 input on current progress and future work plans on data types and procedures defined for LMF-based AI/ML Positioning case 2b. RAN1 response is necessary.

SA2 (in R1-2500389) is requesting RAN1 input on current progress and future work plans on data types defined for case 3b. RAN1 response is necessary - Huaming (vivo).

R1-2501521 Summary#1 on reply LS to SA2 on LMF-based AI/ML Positioning for case 2b and 3b Moderator (vivo)

From Wednesday session

R1-2501522 Draft reply LS on LMF-based AI/ML Positioning for Case 2b vivo, Ericsson

Agreement

Send Reply LS R1-2501522 to SA2 about Case 2b with the content of Section 2 of R1-2501521 by revising

“RAN1 would continue work and may provide additional input in the future to SA2 for Case 2b if any new agreement reached in RAN1.”

“RAN1 may provide additional input in the future to SA2 for Case 2b if any new agreement reached in RAN1.”

Final LS is approved in R1-2501523.

R1-2501524 [DRAFT] reply LS on LMF-based AI/ML Positioning for Case 3b Ericsson, vivo

Agreement

Send Reply LS R1-2501524 to SA2 about Case 3b with the content of Section 3 of R1-2501521 by adding all the agreement made in this meeting for Case 3b.

Final LS is approved in R1-2501525.

R1-2500060 AI/ML for Positioning Accuracy Enhancement Ericsson

R1-2500067 Discussion on AI/ML-based positioning enhancement ZTE Corporation, Pengcheng Laboratory

R1-2500090 Discussion on AI/ML for positioning accuracy enhancement Huawei, HiSilicon

R1-2500202 Discussion on AI/ML-based positioning CATT, CICTCI

R1-2500275 Discussion on specification support for positioning accuracy enhancement CMCC

R1-2500338 Specification support for positioning accuracy enhancement vivo

R1-2500405 Specification support for positioning accuracy enhancement Tejas Networks Limited

R1-2500466 On specification for AI/ML-based positioning accuracy enhancements OPPO

R1-2500518 Discussion on specification support for AI-ML based positioning accuracy enhancement Baicells

R1-2500546 AI/ML based Positioning Google

R1-2500556 Discussion on AIML positioning TCL

R1-2500606 Discussion on specification support for AIML based positioning accuracy enhancement NEC

R1-2500636 Specification impacts for AI/ML positioning Lenovo

R1-2500643 Specification support for AI/ML for positioning accuracy enhancement Sony

R1-2500670 Discussion on specification support for positioning accuracy enhancement Ruijie Networks Co. Ltd

R1-2500687 Specification support for AI-enabled positioning NVIDIA

R1-2500711 Discussion on AI/ML-based positioning accuracy enhancement Xiaomi

R1-2500746 Discussion on support for AIML positioning InterDigital, Inc.

R1-2500767 Discussion on Specification Support for AI/ML-based positioning Apple

R1-2500835 Discussion for supporting AI/ML based positioning accuracy enhancement Samsung

R1-2500901 Discussion on specification support for positioning accuracy enhancement ETRI

R1-2500926 Discussion on specification support for AIML-based positioning accuracy enhancement Fujitsu

R1-2500971 AI/ML for Positioning Accuracy Enhancement Nokia

R1-2500991 AI/ML positioning accuracy enhancement Fraunhofer IIS, Fraunhofer HHI

R1-2501131 Discussion on specification support for AI/ML based positioning accuracy enhancements Sharp

R1-2501145 Specification support for AI-ML-based positioning accuracy enhancement Qualcomm Incorporated

R1-2501191 Discussion on AI/ML for positioning accuracy enhancement NTT DOCOMO, INC.

R1-2501247 Discussion on Specification Support of AI/ML for Positioning Accuracy Enhancement Indian Institute of Tech (M)

R1-2501259 Design for AI/ML based positioning MediaTek Korea Inc.

R1-2501273 Discussion on specification support for AI/ML Positioning Accuracy enhancement CEWiT

R1-2501283 Discussions on specification support for positioning accuracy enhancement for AI/ML ITL

R1-2501410 Summary #1 of specification support for positioning accuracy enhancement Moderator (Ericsson)

From Monday session

Conclusion

For AI/ML based positioning Case 3a, regarding the time stamp in a measurement report from gNB to LMF,

· Existing IE “Time Stamp” in TS 38.455 can be reused from RAN1 perspective.

R1-2501411 Summary #2 of specification support for positioning accuracy enhancement Moderator (Ericsson)

From Tuesday session

Agreement

For Rel-19 AI/ML based positioning, for Case 3b, “FFS: k” in RAN1#119 agreement is resolved by supporting:

· k = {0...5}

Agreement

For Rel-19 AI/ML based positioning, for Case 3b, “FFS: N_t' values” in RAN1#119 agreement is resolved by supporting:

· N_t' = {8, 16, 24}

Agreement

For AI/ML based positioning Case 1, from RAN1 perspective, when the label data of location is generated by LMF and transferred from LMF to UE, label and quality indicator of label can be provided by reusing existing IEs.

· From RAN1 perspective, the existing IE can use one of the geographic shapes defined in TS 23.032. The location estimate uncertainty and confidence (if included with the geographic shapes) can serve as quality indicator of the label.

Agreement

For AI/ML based positioning,

· When channel measurement is to be reported/sent, time stamp of channel measurement refers to the time instance when the channel measurement is performed.

· When label is to be reported/sent, time stamp of label is the time instance for which the label is valid.

R1-2501412 Summary #3 of specification support for positioning accuracy enhancement Moderator (Ericsson)

Presented in Wednesday session

R1-2501413 Summary #4 of specification support for positioning accuracy enhancement Moderator (Ericsson)

From Thursday session

Agreement

For AI/ML based positioning Case 3b, with the existing definition of two channel measurement types (A) or type (B):

(A) path-based measurement, i.e., measurement in the existing specifications (up to Rel-18), (B) Rel-19 enhanced measurement (see definition in RAN1#119 agreement for Case 3b).

Descriptive info of the channel measurement is included together with the channel measurement values, either explicitly or implicitly.
The descriptive info of the channel measurement includes at least:

measurement type (A) or type (B) and
measurement parameters.

Regarding measurement parameters,

For (A) path-based measurement, the measurement parameters include: number of additional paths, k.
For (B) Rel-19 enhanced measurement, the measurement parameters include at least: N_t', k.

FFS: N_t

Note: Type (A) and Type (B) are used for discuss purpose only.

R1-2501414 Summary #5 of specification support for positioning accuracy enhancement Moderator (Ericsson)

From Friday session

Conclusion

For Rel-19 AI/ML based positioning Case 3b,

If the gNB cannot report measurements according to measurement type (A) or measurement type (B) requested by LMF, the gNB responds to LMF that: the gNB cannot provide measurement with the requested measurement type.

The gNB does not respond to LMF with a measurement report where the measurement type is different from requested.

It is up to RAN3 to decide the signaling details.

Note: It is RAN1 understanding that this is the same behavior as in legacy when the NG-RAN node cannot support the requested measurement.

Agreement

RAN1 send an LS to RAN3 and RAN2 to inform them above agreements and conclusions.

Agreement

For training data collection of AI/ML based positioning 3a/3b, if Part A and Part B are generated by different entities, for pairing between a Part A entry and a Part B entry, the following is needed:

The time stamp of Part A (if Part A is transmitted) and the time stamp of Part B (if Part B is transmitted).

FFS: other information is not precluded (e.g., if Part B is valid for a duration)

Note: Purpose such as “training data collection” will not necessarily be specified in RAN1 specifications.

RAN1 send an LS to RAN3 and RAN2 to inform the above.

R1-2501627 [DRAFT] LS on AI/ML Positioning Case 3b Moderator (Ericsson)

Friday decision: The draft LS doesn't seem to correctly capture the agreements.

[Post-120-AI/ML-01] – Yufei (Ericsson)

Email approval of Reply LS on AI/ML Positioning Case 3b by February 26 (Wednesday)

R1-2501629 Final summary specification support for positioning accuracy enhancement Moderator (Ericsson)

9.1.3 Specification support for CSI prediction

R1-2500057 AI/ML for CSI prediction Ericsson

R1-2500068 Discussion on specification support for AI CSI prediction ZTE Corporation, Sanechips

R1-2500091 Discussion on AI/ML for CSI prediction Huawei, HiSilicon

R1-2500160 Discussion on AIML for CSI prediction Spreadtrum, UNISOC

R1-2500203 Discussion on AI/ML-based CSI prediction CATT

R1-2500276 Discussion on AI/ML for CSI prediction CMCC

R1-2500319 Discussion on CSI Prediction TCL

R1-2500339 Specification support for CSI prediction vivo

R1-2500406 Specification support for CSI Prediction Tejas Networks Limited

R1-2500467 On specification for AI/ML-based CSI prediction OPPO

R1-2500533 On AI/ML-based CSI prediction InterDigital, Inc.

R1-2500547 AI/ML based CSI Prediction Google

R1-2500566 Discussions on CSI prediction LG Electronics

R1-2500600 Discussion on specification support for CSI prediction NEC

R1-2500637 Specification support for CSI prediction Lenovo

R1-2500644 Specification Support for AI/ML CSI prediction Sony

R1-2500688 Specification support for AI-enabled CSI prediction NVIDIA

R1-2500712 Discussion on AI/ML model based CSI prediction Xiaomi

R1-2500768 Discussion on AI/ML based CSI prediction Apple

R1-2500816 Discussion on AI/ML-based CSI prediction Panasonic

R1-2500836 Views on AI/ML based CSI prediction Samsung

R1-2500902 Discussion on specification support for CSI prediction ETRI

R1-2500927 Discussion on specification support for CSI prediction Fujitsu

R1-2500972 AI/ML for CSI Prediction Nokia

R1-2501014 AI/ML - Specification support for CSI Prediction MediaTek Inc.

R1-2501080 Discussion on AI/ML for CSI prediction AT&T

R1-2501132 Discussion on specification support for AI/ML based CSI prediction Sharp

R1-2501146 Specification support for CSI prediction Qualcomm Incorporated

R1-2501192 Discussion on AI/ML for CSI prediction NTT DOCOMO, INC.

R1-2501528 Summary #1 of CSI prediction Moderator (LG Electronics)

From Wednesday session

Agreement

For CSI prediction using UE-side model, at least for inference, Rel-18 CSI framework is reused.

For CSI-RS resource type for CMR, periodic, semi-persistent, and aperiodic CSI-RS are supported.
For inference report,

for N4>=1, support Rel-18 codebook ('typeII-Doppler-r18')

R1-2501529 Summary #2 of CSI prediction Moderator (LG Electronics)

R1-2501530 Summary #3 of CSI prediction Moderator (LG Electronics)

From Thursday session

Agreement

For CSI prediction using UE-side model, if performance monitoring type 1 or 3 is supported, for calculation of monitoring metric, support

Based on intermediate KPI

Down select between SGCS and NMSE by RAN1#120bis
FFS on the definition of SGCS/NMSE and how to calculate monitoring metric

Agreement

For CSI prediction using UE-side model, for CSI processing criteria and timeline, at least for inference further study on

· Whether the CPU should be shared or separately counted between legacy CSI reporting and AI/ML-based CSI reporting

· Whether the Processing Unit should be shared or separately counted among AI/ML related features/functionalities.

· Whether new timeline is needed/updated for inference, and whether a different timeline is needed when functionality switches/activates.

· Whether legacy framework for active CSI-RS resource and port counting can be reused

Note: Strive to study CSI processing criteria considering both BM and CSI case, and take the existing solutions as starting point.

R1-2501610 Summary #4 of CSI prediction Moderator (LG Electronics)

Presented in Friday session

Agreement

For CSI prediction using UE-side model, for data collection for training,

For resource configuration,

For CSI-RS resource type for CMR, periodic and semi-persistent are supported.

FFS on support of aperiodic CSI-RS resource

FFS on whether to separately configure CSI-RS resource(s) used for measurements for model input and CSI-RS resource(s) used for measurements for ground-truth CSI
FFS whether/how to enhance CSI-RS resource configuration to reduce CSI-RS signalling overhead.

FFS on CSI report configuration

Final summary in R1-2501626.

9.1.4 Study on AI/ML for NR air interface Phase 2

Please refer to RP-243245 for detailed scope of the SI on AI/ML for NR air interface.

9.1.4.1 CSI compression

R1-2500051 Discussion of CSI compression on AI/ML for NR air interface FUTUREWEI

R1-2500058 AI/ML for CSI compression Ericsson

R1-2500069 Discussion on study for AI/ML CSI compression ZTE Corporation, Sanechips

R1-2500151 Discussion on AI/ML for CSI compression Huawei, HiSilicon

R1-2500161 Discussion on AIML for CSI compression Spreadtrum, UNISOC

R1-2500204 Further study on AI/ML-based CSI compression CATT

R1-2500277 Discussion on AI/ML for CSI compression CMCC

R1-2500340 Discussion on CSI compression vivo

R1-2500407 Discussion on AI/ML for CSI Compression Tejas Networks Limited

R1-2500468 Additional study on AI/ML-based CSI compression OPPO

R1-2500534 On AI/ML-based CSI compression InterDigital, Inc.

R1-2500548 AI/ML based CSI Compression Google

R1-2500558 Discussion on AIML CSI compression TCL

R1-2500567 Study on CSI compression LG Electronics

R1-2500601 Discussion CSI compression NEC

R1-2500638 On AI/ML for CSI compression Lenovo

R1-2500689 Additional study on AI-enabled CSI compression NVIDIA

R1-2500713 Views on two-side AI/ML model based CSI compression Xiaomi

R1-2500769 Discussion on AI based CSI compression Apple

R1-2500817 Discussion on AI/ML for CSI compression Panasonic

R1-2500837 Views on additional study for AI/ML based CSI compression Samsung

R1-2500903 Discussion on AI/ML for CSI compression ETRI

R1-2500928 Discussion on CSI compression with AI/ML Fujitsu

R1-2500973 AI/ML for CSI Compression Nokia

R1-2501015 Additional study on AI/ML for NR air interface - CSI compression MediaTek Inc.

R1-2501119 AI/ML for CSI feedback enhancement Mavenir

R1-2501147 Additional study on CSI compression Qualcomm Incorporated

R1-2501193 Discussion on AI/ML for CSI compression NTT DOCOMO, INC.

R1-2501274 Discussion on AI/ML for CSI compression CEWiT

R1-2501354 Discussion on two-sided AI/ML model based CSI compression IIT Kanpur (rev of R1-2501350)

R1-2501468 Summary#1 of Additional study on AI/ML for NR air interface: CSI compression Moderator (Qualcomm)

From Monday session

Conclusion

Under 10% UCI loss, Case 2 shows small to large performance drop (by Comparing Scenario B and Scenario A). Signaling support to mitigate the UCI loss can improve the performance and helps preserving the gain of Case 2 over Case 0 (by comparing Scenario C and Scenario A and benchmark schemes).

Agreement

Investigate the following approaches for signaling support for mitigating the impact of UCI loss

· NW-signaling to reset of historical CSI information at UE

· NW-triggered CSI retransmission

Conclusion

For direction A, performance impact, if any, due to NW / UE data distribution mismatch with respect to UE side additional condition can be addressed.

Agreement

In Options 3a-1 and 4-1, the exchanged dataset or the model parameters can be associated with an ID for pairing related discussion, then

· The same ID can be used for UE to collect UE-side target CSI for UE-side training

· The same ID can be used for applicability inquiry and reporting

· The same ID can be used for inference configuration

· FFS: whether ID/even same ID is needed for monitoring configuration

· FFS: where the ID is assigned

· Note: whether the purpose for pair will be specified will be discussed separately.

R1-2501469 Summary#2 of Additional study on AI/ML for NR air interface: CSI compression Moderator (Qualcomm)

From Tuesday session

Agreement

For inter-vendor-collaboration Options 3a-1 and 4-1 in Direction A, performance target is confirmed as additional information along with the exchanged dataset or the model parameters.

· FFS: type of performance metric

· FFS: input data for evaluating the performance

Conclusion

Direction C with standardized model ensures a minimum performance requirement.

The so called fully specified reference model discussed in RAN1 for Direction C is assumed to be equivalent to the to-be-specified model, if specified, for performance requirements in RAN4.

Direction A with standardized model parameter / dataset exchange from NW-side to UE-side may achieves better performance.

Conclusion

For NW-first training, in inter-vendor training collaboration Direction A and C, identification of root cause for performance issues can be achieved at least by the following

Data distribution mismatch that is identified by either NW side or UE side
Via target CSI and CSI feedback pair report, e.g., with the understanding that NW side runs inference using the NW side reference CSI generation part and compare with the inference using UE side CSI generation part.
Note that this conclusion does not preclude other methods.
Note that triggering of root cause detection may be after detecting performance degradation

R1-2501470 Summary#3 of Additional study on AI/ML for NR air interface: CSI compression Moderator (Qualcomm)

From Tuesday session

Agreement

For studying the standardized model structure, for temporal domain Case 0, in case of spatial-frequency domain input, adopt the following model structure as one example structure for study purpose,

Encoder description:

Embedding layer

(Note: linear embedding in above figure to be revised to Embedding layer)

Number of tokens

Feature dimension of each token

Output dimension per token

Positional encoding

Number of tokens positions

Dimension of positional encoding for each token position:

Transformer blocks

Number of transformer blocks

Dimension of transformer block

Number of self-attention heads

Dimension of attention head

Dimension of latent space inside feedforward module

Activation function choice

Output linear layer

Reshape the matrix to a vector

Output dimension

Quantization

Scalar quantization:

- Number of bits per latent dimension: N_bit

- Total payload size for Scalar quantization = N_bit * Z_dim

Vector quantization

- segment size = N_seg

- Number of bits per latent dimension: N_bit

- bits per segment = N_bit * N_seg

- Number of segments = Z_dim / N_seg

- Total payload size for Vector quantization = Number of segments * bits per segment

Decoder description:

The decoder has a mirroring design as the encoder. Details are to be discussed.

R1-2501471 Summary#4 of Additional study on AI/ML for NR air interface: CSI compression Moderator (Qualcomm)

From Thursday session

Agreement

For model structure scalability study for temporal domain Case 0,

· For the choice of token dimension and feature dimension,

o Alt 1: Use subband as the token dimension and Tx port as a feature dimension

§ The number of tokens varies with the number of subbands.

o Alt 2: Use Tx port as the token dimension and subband as a feature dimension

§ The number of tokens varies with the number of Tx ports.

o Alt 3: Use a fixed-size sub-block of Tx ports and subbands matrix (e.g., n_Tx_ports*m_Subbands) as a token and represent the input as a sequence of tokens.

§ The number of tokens varies with the number of Tx ports and the number of subbands.

· For scalability over the feature dimension,

o Alt1: specific embedding layer for each feature size

o Alt2: a common embedding layer with padding (e.g., zero-padding or other techniques for padding values)

· For scalability over the token dimension,

o Alt1: positional embedding specific to each token index

§ tokens out of token positions are used as input.

o Alt2: Padding at the input

· For scalability over payload configurations,

o Alt1: specific output linear layer for each payload configuration

o Alt2: truncation/masking of the output linear layer output

o Alt3: by varying quantization parameters

· Notes

o Other Alternatives are not precluded.

o Different Alternatives may be used in combination.

o Same/similar approach is applied at the decoder side.

· Evaluations to consider:

o Case 1 (scalable structure): Scalable model structure described above

§ Using model structure as indicated in above diagram with fixed hyperparameters, companies may train a single parameter set or different parameter sets across different {number of Tx ports, CSI feedback payload size, bandwidth} assuming a common model structure.

§ To report whether a single parameter set or different parameter sets were used across different {number of Tx ports, CSI feedback payload size, bandwidth}. (e.g., single parameter set across different payload sizes and bandwidths, different parameter set across different number of Tx ports)

o Case 2 (dedicated structure): Using model structure as indicated in above diagram with different hyperparameters, where the input and the output related hyperparameters are chosen optimally corresponding to each specific {number of Tx ports, CSI feedback payload size, bandwidth} without scalability considerations.

§ Different parameter sets are trained across different number of Tx ports, CSI feedback payload sizes, and bandwidths.

o For each scalable model structure choice, to evaluate the SGCS performance of the non-AI/ML benchmark (e.g., Rel-16 eType2), Case 1, and Case 2, for each of {number of Tx ports, CSI feedback payload size, bandwidth}, and report the average gain (%) in SGCS of Case 1 and Case 2 over the non-AI/ML benchmark, as well as the loss (%) in the average gain of Case 1 w.r.t. Case 2. The average is performed by first calculating the SGCS gain (%) for each {number of Tx ports, CSI feedback payload size, bandwidth} and then averaging the SGCS gain (%) values over {number of Tx ports, CSI feedback payload size, bandwidth}.

R1-2501472 Summary#5 of Additional study on AI/ML for NR air interface: CSI compression Moderator (Qualcomm)

From Friday session

Agreement

For model structure scalability study for temporal domain Case 0, for the choice of {number of Tx ports, CSI feedback payload size, bandwidth}, take the following as baseline values.

Number of Tx ports

[N1, N2, P] = [2, 8, 2] (32 CSI-RS ports)
[N1, N2, P] = [4,4,2] (32 CSI-RS ports)
[N1, N2, P] = [2, 4, 2] (16 CSI-RS ports)

CSI feedback payload size

Multiple values, encouraged to pick at least one value from each of small, medium, and large payload regions X, Y, and Z.

Bandwidth & subband size

All subbands
A subset of all the subbands.

Agreement

Capture the following observations into TR:

For the evaluation of performance impact due to UE-side / NW-side data distribution mismatch with respect to UE-side additional condition (issue 4 and 6),

When dataset A include dataset B, for case 2, option 3a-1, with NW-side target CSI sharing

· 1 source [Panasonic] observes minor performance loss (-0.22% ~ -1.09%) relative to case 1 with NW side target CSI sharing.

When dataset A include dataset B, for case 2, option 3a-1, without NW-side target CSI sharing,

· 1 2 source [ZTE,vivo] observes minor performance loss (~~-0.67~~ -0.006% ~ -0.97%) related to case 1 without NW side target CSI sharing.

· 1 source [OPPO] observes moderate performance loss (-3.3% ~ -4%) relative to case 1 without NW side target CSI sharing

When dataset A include dataset B, for case 3 (Direction B),

· 1 2 source [ZTE,vivo] observes minor performance loss (~~-0.6% ~ -0.9%~~ -0.9% ~ +0.01%) relative to case 1.

When dataset A does not include dataset B, for case 2, option 3a-1, with NW-side target CSI sharing

· 3 sources [QC, Apple, Samsung] observe similar performance (-0.4% ~ +0.24%) as case 1 for Alt1 UE training.

· 3 sources [vivo, Xiaomi, ETRI] observe minor performance loss up to -2.5% relative to case 1 for Alt1 training.

· 1 2 source [Ericsson, ZTE] observe moderate performance loss of (-3.8 ~ -8.3%) relative to case 1 for Alt1 training.

· 1 source [OPPO] observe significant performance loss (-51% ~ -62.5%) relative to case 1 for Alt1 UE training.

· 2 sources [CATT, Futurewei] observe minor performance loss (-1.62% ~~-2.78%~~ ~ -3.2%) relative to case 1 for Alt2 UE training

· 1 source [Apple] observe moderate loss of -6.7% relative to case 1 for Alt2 UE training.

When dataset A does not include dataset B, for case 2, option 3a-1, without NW-side target CSI sharing

· 4 5 sources [CATT, ZTE, Xiaomi, ETRI, vivo] observe minor to moderate performance loss (-0.4% ~ -3.9%) relative case 1.

· 2 3 source [QC, Ericsson, Apple] observe moderate performance loss (-6.7% ~ -8.6%) relative to case 1.

· 1 source [OPPO] observes significant performance loss of -62.1% relative to case 1.

When dataset A does not include dataset B, for case 2, option 4-1,

· 4 sources [QC, Apple, Xiaomi, ETRI] observe zero to minor performance loss (-2.4% ~ 0%) relative to case 1 for Alt1 UE training.

· 1 source [Ericsson] observe minor to moderate performance loss (-2.9% ~ -7.9%) relative to case 1 for Alt1 UE training depending on whether dataset A applies augmentation using various phase normalization methods.

· 4 sources [CATT, Xiaomi, Futurewei, ETRI] observe minor performance loss (-1.41% ~ -3.52%) relative to case 1 for Alt2 UE training.

· 1 source [Apple] observes moderate loss of -7.9% relative to case 1 for Alt2 UE training.

· 1 source [vivo] observes moderate loss of -7.7% relative to case 1 for 3a-1 for Alt1 UE training when backbone are different.

When dataset A does not include dataset B, for case 3, Direction B,

· 4 sources [CATT, vivo, ZTE, ETRI] observe minor loss to positive gain (-3.7% ~ 1%) relative to case 1.

· 1 source [QC] observes significant loss (-20%) relative to case 1.

Agreement

Capture the following observations into TR:

For the evaluation of performance impact due to mismatch between the distribution of the dataset used for reference model(s) training, UE-side data distribution, and NW-side data distribution (Issue 9),

For case 2 (model trained on dataset S but tested on dataset B),

· 2 sources [vivo, QC] observe significant performance loss (-7.2% ~ -17.4%) relative to case 1, where dataset B consists of actual field data.

· 1 source [ETRI] observes significant performance loss of -37.3% relative to case 1, where dataset S and B are different by TxRU mapping.

· 3 resources [ZTE, Panasonic, Ericsson] observe moderate performance loss (-2.12% ~ -4.75%) relative to case 1, where dataset S and B are generated from different scenarios, antenna layout or UE location. E.g., Uma and InH respectively, or dataset S and B are different by antenna layout and indoor/outdoor ratio.

For case 2A (model further finetuned on dataset B),

· If finetune at NW and fix encoder at UE

o For using actual field data as dataset B

§ When dataset A / B mismatch is considered but dataset B does not contain A, 1 source [vivo] observe moderate loss (-4.63% ~ -7.66%) relative to case 1. The improvement compared to case 2 is minor to moderate (2.58% ~ 9.17%).

§ When dataset A / B mismatch is not considered, 2 1 sources [~~vivo,~~ QC] observes minor ~~to moderate~~ loss of (-3.5% ~~~ -7.66%)~~ loss relative to case 1. The improvement compared to case 2 is moderate to significant (2.6% ~ 13.9%) depending on the specific scenario where the field data is collected.

o For using synthetic data as dataset B

§ When dataset A / B mismatch is considered but dataset B does not contain A, 1 source [ZTE] observes moderate loss to case 1 (-4.32% ~ -4.75%). The improvement compared to case 2 is negative (-0.68% ~ -1.02%).

§ When dataset A includes or is the same as dataset B, 3 sources [ZTE, Panasonic, Ericsson] observe minor to moderate loss relative to case 1 (-0.97% ~ -4.67%). The improvement compared to case 2 is ~~negative to~~ minor (-0.6~~1.01~~% ~ 1.6149%). Dataset S and B are Uma and InH respectively, or dataset S and B are different by antenna layout and indoor/outdoor ratio.

· If finetune at UE and fix decoder at NW

o For using actual field data as dataset B,

§ 2 sources [vivo, QC] observe moderate to significant loss (-6.8% ~ -12%) relative to case 1. The improvement compared to case 2 is minor moderate (0.4% ~ 7.1%) depending on the specific scenario where the field data is collected.

o For using synthetic data as dataset B

§ 2 source [Panasonic, Ericsson] observe minor to moderate loss (-1.56% ~ -3.81%) relative to case 1. The improvement compared to case 2 is marginal (0.03% ~ 0.75%). Dataset S and B are different by antenna layout and indoor/outdoor ratio.

§ 1 source [ETRI] observes significant loss (-23.8%) relative to case 1. The improvement compared to case 2 is significant (13.5%). Dataset S and B are different by TxRU mapping

· If finetune at both UE and ~~both~~ NW sides

o For using actual field data as dataset B

§ When dataset A / B mismatch is considered and dataset A does not contain B, 1 source [vivo] observes significant loss (-8.5% ~ -44.85%) relative to case 1 depending on specific scenarios for data collection. The improvement compared to case 2 is negative (-28% ~ -1.3%). The loss relative to finetune at one side is negative (-1.72% ~ -37.19%).

§ When dataset A / B mismatch is not considered and A is equal to B, 1 2 sources [~~vivo,~~ QC] observes moderate ~~to significant~~ loss of (-7.3% ~~~ -56.1%)~~ relative to case 1. The improvement compared to case 2 is ~~negative to~~ significant ~~(-39.3% ~~~ 10.1%). The loss relative to finetune at one side is ~~minor to significant (-1.7 ~ 48.4%)~~ negative to moderate (-3.82~ 4.67%).

o For using synthetic data as dataset B

§ When dataset A / B mismatch is modelled by different scenarios (i.e., by NW side condition),

· If the input is in spatial-frequency domain, 1 source [Samsung] observes minor to significant loss (-29.0% ~ -30.5%) relative to case 1 depending on whether data Set S is used in the finetune.

· If the input is in angle-delay domain, 1 source [Samsung] observes similar performance to case 1 (-0.3% ~-1.3%)

§ When dataset A includes B or is equal to B or has same distribution as B,

· If the input is in spatial-frequency domain, and dataset A does not contain B, 2 sources [Panasonic, Ericsson] observe minor to moderate loss (-1.1% ~ -3.69%) relative case 1 depending on the modelling of synthetic data. The improvement compared to case 2 is minor (0.57% ~ 1.3%). Compared to finetune at one side, the performance improvement is similar to minor (-0.35% ~ 1%).

· If the input is in spatial-frequency domain, 1 source [Samsung] observes minor to significant loss (-3.67% ~ -11.18%) relative to case 1 depending on whether data Set S is used in the finetune.

· If the input is in angle-delay domain, 1 source [Samsung] observes similar performance to case 1 (-0.89% ~1.51%).

§ When dataset A / B mismatch is modelled by Rx antenna spacing and dataset A does not contain B and dataset A has same distribution as S (i.e., synthetic/field data distribution mismatch modeled only at the UE side (via UE-side additional condition) but not modeled at the NW-side), 1 source [Samsung] observes similar performance (-0.89% ~ 0.21%) as case 1.

Agreement

Study performance-complexity trade-off by comparing different AI/ML models, e.g. by optimizing existing designs, and/or by comparing different precoder representation in (spatial-frequency and angle-delay) or (spatial-frequency-time and angle-delay-doppler), by considering the following aspects

· Performance comparison between different AI/ML designs and benchmark schemes

· Complexity numbers (FLOP, calculated/projected latency or power consumption if available, measured latency or power consumption if available) of different AI/ML designs and benchmark schemes

R1-2501474 Final summary of Additional study on AI/ML for NR air interface: CSI compression Moderator (Qualcomm)

9.1.4.22 Other aspects of AI/ML model and data

Including model identification/procedure for two-sided model, collection of UE-sided model training data, and model transfer/delivery

R1-2500052 Discussion on other aspects of AI/ML model and data on AI/ML for NR air-interface FUTUREWEI

R1-2500070 Discussion on other aspects of AI/ML model and data ZTE Corporation, Sanechips

R1-2500152 Discussion on other aspects of the additional study for AI/ML Huawei, HiSilicon

R1-2500162 Discussion on other aspects of AI/ML model and data Spreadtrum, UNISOC

R1-2500205 Further study on AI/ML for other aspects CATT, CICTCI

R1-2500255 Discussion on other aspects of AI ML model and data China Telecom

R1-2500278 Discussion on other aspects of AI/ML model and data CMCC

R1-2500341 Other aspects of AI/ML model and data vivo

R1-2500392 Discussion on other aspects of AI/ML Ericsson

R1-2500408 Other aspects of AI/ML Model and Data Tejas Networks Limited Withdrawn

R1-2500469 Additional study on other aspects of AI/ML model and data OPPO

R1-2500549 AI/ML Model and Data Google

R1-2500559 Discussions on other aspects of AlML In NR air interface TCL

R1-2500568 Discussion on other aspects of AI/ML model and data LG Electronics

R1-2500591 Discussion on other aspects of AI/ML model and data NEC

R1-2500639 Discussion on other aspects of AI/ML model and data Lenovo

R1-2500690 Additional study on other aspects of AI model and data NVIDIA

R1-2500714 Further study on AI/ML model and data Xiaomi

R1-2500770 Discussion on other aspects of AI/ML models and data Apple

R1-2500815 Discussion on the terminology alignment TR in SA Panasonic

R1-2500838 Views on additional study for other aspects of AI/ML model and data Samsung

R1-2500904 Discussion on other aspects of AI/ML model and data ETRI

R1-2500929 Discussion on other aspects of AI/ML model and data Fujitsu

R1-2500974 Other aspects of AI/ML for two-sided model Nokia

R1-2500976 Discussion on other aspects of AI/ML model and data Continental Automotive

R1-2501079 Other Aspects of AI/ML framework AT&T

R1-2501148 Other aspects of AI/ML model and data Qualcomm Incorporated

R1-2501194 Discussion on other aspects of AI/ML model and data NTT DOCOMO, INC.

R1-2501403 Summary #1 for other aspects of AI/ML model and data Moderator (OPPO)

From Wednesday session

Agreement

From RAN1 perspective, for the study of delivery/transfer Case z4, if the known structured model is specified in 3GPP, at least consider the following for the open format.

Define an open format within 3GPP.

R1-2501404 Summary #2 for other aspects of AI/ML model and data Moderator (OPPO)

From Thursday session

Conclusion

From RAN1 perspective, the study progress of model identification and model transfer/delivery in Agenda item 9.1.4.2 are sufficient.

New work/discussion in AI 9.1.4.2 can be triggered by LS from other working group(s) or other TSG(s), if any
The work on pCR (if any) to capture the output of AI 9.1.4.2 to be done in future meeting(s)
Other on-demand work (if any)

From RAN1 perspective, there is no consensus in Rel-19 on the need of standardized solution for model delivery/transfer of one-sided model
In RAN1, if needed, whether model identification is needed for CSI compression or not is to be decided in Agenda item 9.1.4.1
In RAN1, if needed, whether standardized solution(s) for model transfer/delivery are needed for CSI compression or not is to be decided in Agenda item 9.1.4.1

Final summary in R1-2501406.

RAN1#120-bis

9.1 Artificial Intelligence (AI)/Machine Learning (ML) for NR Air Interface

Please refer to RP-250792 for detailed scope of the WI.

R1-2503111 Session notes for 9.1 (AI/ML for NR Air Interface) Ad-Hoc Chair (CMCC)

Friday decision: The session notes are endorsed and contents reflected below.

[120bis-R19-AI/ML] – Taesang (Qualcomm)

Email discussion on Rel-19 AI/ML

- To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc

R1-2502828 Rapporteur view on higher layer signalling of Rel-19 AI-ML for NR air interface Qualcomm Incorporated

9.1.1 Specification support for beam management

R1-2501717 Discussion on specification support for AI/ML-based beam management FUTUREWEI

R1-2501751 Specification Support for AI/ML for Beam Management Kyocera

R1-2501775 AI/ML for beam management Ericsson

R1-2501795 Specification support for beam management vivo

R1-2501858 Discussion on AIML for beam management Spreadtrum, UNISOC

R1-2501905 Discussion on AI/ML-based beam management ZTE Corporation, Sanechips

R1-2501938 Specification support for AI-enabled beam management NVIDIA

R1-2501946 AI/ML based Beam Management Google

R1-2501959 Discussion on AIML beam management TCL

R1-2501968 Specification support for AI/ML-based beam management CATT

R1-2502036 Discussion on AI/ML for beam management Ofinno

R1-2502066 Discussion on specification support for beam management Panasonic

R1-2502078 Discussion on specification support for beam management NEC

R1-2502097 Specification support for beam management Tejas Network Limited

R1-2502099 Discussions on AI/ML for beam management LG Electronics

R1-2502115 Discussion on specification support on AI/ML for beam management Fujitsu

R1-2502149 Discussion on specification support for beam management CMCC

R1-2502193 AI/ML specification support for beam management Lenovo

R1-2502210 Discussion on AIML for beam management Huawei, HiSilicon

R1-2502288 On specification for AI/ML-based beam management OPPO

R1-2502301 Discussion on AI/ML for beam management InterDigital, Inc.

R1-2502309 Discussion on specification support for beam management Sony

R1-2502352 Discussion for supporting AI/ML based beam management Samsung

R1-2502411 Discussion on specification support for beam management Ruijie Networks Co. Ltd

R1-2502430 Discussion on AI/ML for beam management Xiaomi

R1-2502501 Discussion on specification support for beam management ETRI

R1-2502528 AI/ML for Beam Management Nokia

R1-2502537 Discussion on specification support for AI/ML beam management Transsion Holdings

R1-2502585 Specification support for AI/ML beam management ITL

R1-2502594 AI/ML for beam management Apple

R1-2502683 Discussions on specification support for beam management Sharp

R1-2502686 Discussion on AI/ML for beam management HONOR

R1-2502700 Specification support for beam management KDDI Corporation (TTC)

R1-2502701 Discussion on specification support for AIML-based beam management MediaTek Inc.

R1-2502728 Discussion on AI/ML based beam management KT Corp.

R1-2502755 Discussion on AI/ML for beam management NTT DOCOMO, INC.

R1-2502829 Specification support for AI-ML-based beam management Qualcomm Incorporated

R1-2502876 Discussion on AIML based beam management ASUSTeK

R1-2502894 On Performance Monitoring for Beam Management Use Case NTU

R1-2502895 Specification support for beam management Fraunhofer HHI, Fraunhofer IIS

R1-2503040 FL summary #0 for AI/ML in beam management Moderator (Samsung)

From Monday session

Agreement

For UE-sided model, regarding the resource type for data collection purpose, only always-on SSB and P/SP CSI-RS are supported.

Agreement

For BM-Case1, for the Top K beam(s) report as the inference results

· K is configured in inference report configuration to the UE.

Agreement

For UE-sided model inference, support the following report format (i.e., CSI field mapping order) for BM-Case1, for beam information on predicted Top K beam(s) among a set of beams and RSRP of predicted Top K beam(s) among a set of beams

CRI or SSBRI #1

CRI or SSBRI #2

…

CRI or SSBRI #K

RSRP #1

differential RSRP #2

…

differential RSRP #K

CRI or SSBRI #k is mapped to RSRP #k, where k = 1,2,…,K.
RSRP #1 is absolute predicted RSRP.
Differential RSRP #2~#K are differential predicted RSRP with reference to the largest predicted RSRP corresponding to CRI or SSBRI #1.

Agreement

For UE-sided model inference, support the following report format (i.e., CSI field mapping order) for BM-Case2, for beam information on predicted Top K beam(s) among a set of beams and RSRP of predicted Top K beam(s) among a set of beams

Time instance indicator

CRI or SSBRI #1 of time instance #1

CRI or SSBRI #2 of time instance #1

…

CRI or SSBRI #K of time instance #1

CRI or SSBRI #1 of time instance #2

CRI or SSBRI #2 of time instance #2

…

CRI or SSBRI #K of time instance #2

…

CRI or SSBRI #1 of time instance #N

CRI or SSBRI #2 of time instance #N

…

CRI or SSBRI #K of time instance #N

RSRP #1 of time instance #1

Differential RSRP #2 of time instance #1

…

Differential RSRP #K of time instance #1

Differential RSRP #1 of time instance #2

Differential RSRP #2 of time instance #2

…

Differential RSRP #K of time instance #2

…

Differential RSRP #1 of time instance #N

Differential RSRP #2 of time instance #N

…

Differential RSRP #K of time instance #N

· Time instance indicator exist if N > 1.

· The size of CSI field for time instance indicator is .

· The value of time instance indicator n (n≥0) corresponds to the (n+1)-th earliest time instance in the N time instances.

· Time instance #1 corresponds to the time instance indicated by the time instance indicator.

· Time instance #2~#N are mapped to the remaining N-1 time instance(s) other than time instance #1 based on the time domain order of the time instances.

· where time instance #2 is mapped to the earliest time instance from the N-1 time instance(s).

· CRI or SSBRI #k is mapped to RSRP #k with the same time instance, where k = 1,2,…,K.

· RSRP #1 of time instance #1 is absolute RSRP; and the remaining RSRP are differential RSRP with reference to the largest predicted RSRP corresponding to CRI or SSBRI #1 of time instance #1.

R1-2503041 FL summary #1 for AI/ML in beam management Moderator (Samsung)

From Tuesday session

Agreement

For BM-Case 2 of UE-side model, one RRC parameter represents the time gap configured for between two consecutive future time instances, and also represents the time gap between the reference time and the first future time instance for prediction.

Agreement

For UE-sided model monitoring Type 1 option 2, regarding the type of resource for the set for monitoring, support at least periodic CSI-RS, semi-persistent CSI-RS and SSB.

Agreement

For UE-sided model monitoring Type 1 option 2, support the following combination for inference report type and monitoring report type:

Monitoring report type Inference report type	P report	SP report	AP report
AP report	Not support	Not support	Support
SP report	Not support	Support	Support
P report	Support	Support	Support

Agreement

For UE-sided model, regarding a CSI report corresponding to CSI-ReportConfig for Type 1 option 2 monitoring, .

Note: The occupation duration is a separate discussion.

R1-2503042 FL summary #2 for AI/ML in beam management Moderator (Samsung)

From Wednesday session

Agreement

For UE-sided AI/ML model for beam management, for Option 2 (UE-assisted performance monitoring), the performance metric of Top 1 or Top K beam prediction accuracy is defined as:

· At least one of the Top M beam(s) of the resource set(s) for monitoring is among Top-K predicted beam(s) of Set A (e.g., linked to at least one of the Top-K predicted beam(s) of Set A based on certain rule or signalling)

o Where K is the number of predicted beam(s) in the corresponding inference report per time instance

o Where Top M beam(s) is the best M beam(s) based on L1-RSRP measurements of the resource set(s) for monitoring

o M is configured by NW in CSI report configuration for monitoring

§ M= 1, 2

o FFS: detailed rule or signalling

Agreement

For calculation the performance metric of Type 1 Option 2 performance monitoring for UE-sided model:

· Support the size of a set for monitoring is the same as the size of Set A.

o The n-th resource in the set for monitoring is linked to the n-th resource in Set A.

· Support the size of a set for monitoring is smaller than the size of Set A.

Working Assumption

At least for the monitoring Type 1 Option 2 of UE-side model monitoring, for calculation of metric for monitoring,

for BM-Case 1, measurement result of a transmission occasion of the CSI-RS/SSB resources for monitoring is linked with an inference report, where the CSI reference resource of the corresponding inference report has the minimal slot offset to the transmission occasion of the CSI-RS/SSB resources for monitoring.

Wherein, the corresponding inference report, and the transmission occasion of the CSI-RS/SSB resources for monitoring are no later than the CSI reference resource corresponding to the CSI report for monitoring
FFS: whether to introduce a threshold X for the minimal slot offset, and whether it is optionally configured by RRC, where the minimal slot offset k is no larger than X; otherwise, the transmission occasion for monitoring has no linked inference report.

R1-2503043 FL summary #3 for AI/ML in beam management Moderator (Samsung)

From Thursday session

Working Assumption

For BM-Case 1, the beam prediction accuracy is calculated based on N latest transmission occasion(s) of monitoring resources with linked inference report no later than CSI reference resource corresponding to the CSI report for monitoring

wherein N (N>=1) is configured in CSI-ReportConfig

FFS on additional rule for counting N linked pair

For BM-Case 1, one resource set for monitoring is configured in one CSI-ReportConfig for monitoring.

Conclusion

For UE-sided model, for BM-Case 2, for inference, AP CSI-RS for Set B is not supported.

Agreement

· For UE-side model, for AI/ML based beam management for BM-Case 1 and BM-Case 2, for processing of a CSI report for inference, considering the following options for potential down selection:

o Option 1: only dedicated AI/ML PU is occupied, is reported by UE.

§ And

o Option 2: only legacy CPU is occupied, it is reported by UE.

o Option 3: both dedicated AI/ML PU and legacy CPU are occupied, is reported by UE.

§ And

Note: The supported option by UE is reported by UE capability, if multiple options are supported.

· The total number of dedicated AI/ML PU for AI/ML is reported by UE capability.

o Note: The total number of Use case specific dedicated AI/ML PU could be discussed separately.

R1-2503044 FL summary #4 for AI/ML in beam management Moderator (Samsung)

From Friday session

Working Assumption

For BM-Case 2, at least support to report one beam prediction accuracy for one configured time instance, configured by one CSI-ReportConfig for monitoring,

· only one resource set is configured in the CSI-ReportConfig

· the one configured time instance (i.e. f-th time instance of the time instance in one inference report) for metric calculation is configured in the CSI-ReportConfig for monitoring

o FFS on whether to configure more than one time instance

· the performance metric of the f-th time instance is calculated based on N latest transmission occasion(s) of monitoring resource with linked time instance, no later than CSI reference resource corresponding to the CSI report for monitoring

o N (N>=1) is configured in the CSI-ReportConfig

o FFS on additional rule for counting N linked pair

o measurement result of a transmission occasion of the CSI-RS/SSB resources for monitoring is linked with the f-th time instance for prediction, where the f-th time instance has the minimal slot offset to the transmission occasion of the CSI-RS/SSB resources for monitoring.

§ Wherein, the corresponding inference reports, and the transmission occasions of the CSI-RS/SSB resources for monitoring, [FFS on the f-th time instances] are no later than the CSI reference resource corresponding to the CSI report for monitoring.

§ FFS: whether to introduce a threshold X, and whether it is optionally configured by RRC, where the minimal slot offset k is no larger than X; otherwise, the transmission occasion for monitoring has no linked time instance.

9.1.2 Specification support for positioning accuracy enhancement

R1-2501796 Specification support for positioning accuracy enhancement vivo

R1-2501859 Discussion on AIML for positioning accuracy enhancement Spreadtrum, UNISOC

R1-2501917 Discussion on AI/ML-based positioning enhancement ZTE Corporation, Pengcheng Laboratory

R1-2501925 Discussion on support for AIML positioning InterDigital, Inc.

R1-2501940 Specification support for AI-enabled positioning NVIDIA

R1-2501947 AI/ML based Positioning Google

R1-2501969 Specification support for AI/ML-based positioning CATT, CICTCI

R1-2502064 Discussion on specification support for positioning accuracy enhancement TCL

R1-2502071 Discussion on specification support for AIML based positioning accuracy enhancement NEC

R1-2502098 Specification support for positioning accuracy enhancement Tejas Network Limited

R1-2502116 Discussion on specification support for AIML-based positioning accuracy enhancement Fujitsu

R1-2502150 Discussion on specification support for positioning accuracy enhancement CMCC

R1-2502194 Specification impacts for AI/ML positioning Lenovo

R1-2502211 Discussion on AI/ML for positioning accuracy enhancement Huawei, HiSilicon

R1-2502289 On specification for AI/ML-based positioning accuracy enhancements OPPO

R1-2502310 Discussion on Specification support for positioning accuracy enhancement Sony

R1-2502353 Discussion for supporting AI/ML based positioning accuracy enhancement Samsung

R1-2502412 Discussion on specification support for positioning accuracy enhancement Ruijie Networks Co. Ltd

R1-2502431 Discussion on AI/ML-based positioning accuracy enhancement Xiaomi

R1-2502502 Discussion on specification support for positioning accuracy enhancement ETRI

R1-2502529 AI/ML for Positioning Accuracy Enhancement Nokia

R1-2502561 AI/ML positioning accuracy enhancement Fraunhofer IIS, Fraunhofer HHI

R1-2502595 Specification Support for AI/ML-based positioning Apple

R1-2502660 AI/ML for Positioning Accuracy Enhancement Ericsson

R1-2502663 Design for AI/ML based positioning MediaTek Korea Inc.

R1-2502684 Discussion on specification support for AI/ML based positioning accuracy enhancements Sharp

R1-2502756 Discussion on AI/ML for positioning accuracy enhancement NTT DOCOMO, INC.

R1-2502830 Specification support for AI-ML-based positioning accuracy enhancement Qualcomm Incorporated

R1-2502911 Discussion on specification support for AI/ML positioning accuracy enhancement CEWiT

R1-2502933 Discussions on specification support for positioning accuracy enhancement for AI/ML ITL

R1-2502987 Summary #1 of specification support for positioning accuracy enhancement Moderator (Ericsson)

From Monday session

Conclusion

The offset (used in the agreement made in RAN1#119) refers to the duration (in samples) between the reference time and the starting time of the list of N_t consecutive values.

Agreement

For Rel-19 AI/ML based positioning, for Case 3b, “FFS: whether transmit offset from gNB to LMF” in RAN1#119 agreement is resolved by:

· No offset is transmitted from gNB to LMF.

Conclusion

For channel measurement type (A) (i.e., path-based measurement), it is not necessary to introduce enhancements on the number of reported paths in Rel-19.

R1-2502988 Summary #2 of specification support for positioning accuracy enhancement Moderator (Ericsson)

From Tuesday session

Agreement

For model performance monitoring of AI/ML positioning Case 1, “FFS: content of monitoring outcome” in RAN1#119 agreement is resolved by:

· the content of monitoring outcome includes at least an indication that the target UE cannot perform the Case 1 positioning method.

R1-2502989 Summary #3 of specification support for positioning accuracy enhancement Moderator (Ericsson)

Presented in Wednesday session.

R1-2502990 Summary #4 of specification support for positioning accuracy enhancement Moderator (Ericsson)

Presented in Thursday session.

R1-2502991 Summary #5 of specification support for positioning accuracy enhancement Moderator (Ericsson)

From Friday session

Agreement

For training data collection of Part B in AI/ML based positioning Case 3a, for the case when Part B label includes timing information, support the following for providing label and quality indicator of label,

the corresponding label is provided by LMF to gNB in the format of timing information. “Timing Measurement Quality” in 38.455 can serve as quality indicator of the label.

Note: It is assumed that user data privacy of non-PRU UE is preserved.

Conclusion

For training data collection of Part B in AI/ML based positioning Case 3a, for the case when Part B label includes the LOS/NLOS indicator,

the corresponding label is provided from LMF to the gNB by using the existing IE LOS-NLOS-Indicator-r17. There is no need of a separate field for quality indicator of LOS/NLOS indicator.

R1-2503144 Final summary of specification support for positioning accuracy enhancement Moderator (Ericsson)

9.1.3 Specification support for CSI prediction

R1-2501797 Specification support for CSI prediction vivo

R1-2501848 Discussion on AI-based CSI prediction TCL

R1-2501860 Discussion on AIML for CSI prediction Spreadtrum, UNISOC

R1-2501918 Discussion on specification support for AI CSI prediction ZTE Corporation, Sanechips

R1-2501923 AI/ML for CSI prediction Ericsson

R1-2501931 Discussion on CSI Processing Unit FUTUREWEI

R1-2501939 Specification support for AI-enabled CSI prediction NVIDIA

R1-2501945 Discussions on AI/ML for CSI prediction KT Corp.

R1-2501948 AI/ML based CSI Prediction Google

R1-2501970 Specification support for AI/ML-based CSI prediction CATT

R1-2502072 Discussion on specification support for CSI prediction NEC

R1-2502100 Discussions on CSI prediction LG Electronics

R1-2502117 Discussion on specification support for CSI prediction Fujitsu

R1-2502151 Discussion on AI/ML for CSI prediction CMCC

R1-2502195 Specification support for CSI prediction Lenovo

R1-2502212 Discussion on AIML for CSI prediction Huawei, HiSilicon

R1-2502290 On specification for AI/ML-based CSI prediction OPPO

R1-2502311 Specification Support for AI/ML CSI prediction Sony

R1-2502337 On AI/ML-based CSI prediction InterDigital, Inc.

R1-2502354 Views on AI/ML based CSI prediction Samsung

R1-2502413 Discussion on specification support for CSI prediction Ruijie Networks Co. Ltd

R1-2502432 Further discussion on AI/ML model based CSI prediction Xiaomi

R1-2502472 Specification support for CSI Prediction Tejas Network Limited

R1-2502491 Discussion on AI/ML-based CSI prediction Panasonic

R1-2502503 Discussion on specification support for CSI prediction ETRI

R1-2502530 AI/ML for CSI Prediction Nokia

R1-2502567 Specification support for CSI prediction Continental Automotive

R1-2502596 Discussion on AI based CSI prediction Apple

R1-2502685 Discussion on specification support for AI/ML based CSI prediction Sharp

R1-2502702 AI/ML - Specification support for CSI Prediction MediaTek Inc.

R1-2502735 Discussion on AI/ML for CSI prediction AT&T

R1-2502757 Discussion on AI/ML for CSI prediction NTT DOCOMO, INC.

R1-2502831 Specification support for CSI prediction Qualcomm Incorporated

R1-2503056 Summary #1 of CSI prediction Moderator (LG Electronics)

From Tuesday session

Agreement

Introduce a dedicated AI/ML PU for AI/ML features for UE,

· The AI/ML PU is used at least for quantifying the simultaneous processing of multiple CSI reports subject to CSI-related AI/ML use case(s), e.g., CSI compression (if supported), CSI prediction, BM spatial prediction, BM temporal prediction.

Conclusion

For CSI prediction using UE-side model, for data collection for training, aperiodic CSI-RS resource for CMR is not supported.

Agreement

For CSI prediction using UE-side model, for training data collection, support

· CSI-ReportConfig can used for configuring the resources for data collection purpose without CSI report.

o FFS on how to indicate without CSI report in CSI-ReportConfig.

Agreement

For CSI prediction using UE-side model, for performance monitoring, support UE assisted performance monitoring subject to an additional UE capability, and UE assisted performance monitoring is based on Type 3 performance monitoring.

R1-2503057 Summary #2 of CSI prediction Moderator (LG Electronics)

From Wednesday session

Agreement

For CSI prediction using UE-side model, for performance monitoring type 3, support SGCS as a performance metric.

Agreement

For the definition of SGCS,

Note: How to handle layer mapping mismatch, if any, is up to UE implementation.

R1-2503058 Summary #3 of CSI prediction Moderator (LG Electronics)

From Thursday session

Agreement

For CSI prediction using UE-side model, for reporting contents of UE assisted performance monitoring, down-select one alternative by RAN1#121.

Alt 1: one SGCS is calculated based on predicted CSI for one inference reporting, ground truth CSI
Alt 2: one SGCS is calculated based on predicted CSI for one inference reporting, and ground truth CSI, another SGCS is based on ground truth CSI and CSI (non-predicted) corresponding to the latest CSI-RS transmission occasion not later than CSI reference resource of the inference reporting instance.
Alt 3: statistic of reporting contents (e.g., mean, x% CDF of SGCS values) of inference reporting instances within configured monitoring window

Monitoring window can be configured by NW

FFS on signalling details

FFS on whether to report per prediction instance, selected prediction instance(s), averaged over prediction instances
FFS on report frequency granularity (e.g., per wideband or per subband or averaged over subband or selected subband)
FFS on whether to report per layer, the first layer, averaged over layer
FFS on how to quantize and report mechanism

R1-2503059 Summary #4 of CSI prediction Moderator (LG Electronics)

From Friday session

Agreement

For CSI prediction using UE side model, for inference, consider following options for potential down selection:

· Option 1: only dedicated AI/ML PU (O_APU) is occupied.

· Option 2: only legacy CPU (O_CPU) is occupied.

· Option 3: both dedicated AI/ML PU (O_APU) and legacy CPU (O_CPU) are occupied.

· FFS whether O_APUand O_CPUare based on defined rule and/or reported by UE.

· Note: The supported option(s) by UE is reported by UE capability, if multiple options are supported.

The total number of dedicated AI/ML PU for AI/ML is reported by UE capability.

· Note: The total number of Use case specific dedicated AI/ML PU could be discussed separately.

Agreement

For CSI prediction using UE-side model, at least for inference, introduce new RRC parameter for CSI report configuration to distinguish CSI report of AI-CSI prediction and non-AI CSI prediction.

· Note: terminology of “AI-CSI prediction” and “non-AI CSI prediction” is separate discussion.

· Detailed parameter name is up to RAN2.

Final summary in R1-2503139.

9.1.4 Study on AI/ML for NR air interface Phase 2

Please refer to RP-250308 for detailed scope of the SI on AI/ML for NR air interface.

9.1.4.11 CSI compression and any other aspects on AI/ML model/data

Including any remaining discussions on “Processing Unit”.

R1-2502996 Discussion of CSI compression on AI/ML for NR air interface FUTUREWEI (rev of R1-2501718)

R1-2501798 Discussion on CSI compression and other aspects on AI/ML model/data vivo

R1-2501861 Discussion on AIML for CSI compression Spreadtrum, UNISOC

R1-2501919 Discussion on study for AI/ML CSI compression ZTE Corporation, Sanechips

R1-2502952 AI/ML for CSI compression and other aspects on AI/ML model/data Ericsson (rev of R1-2501924)

R1-2501934 Additional study on AI-enabled CSI compression and other aspects of AI model and data NVIDIA

R1-2501949 AI/ML based CSI Compression Google

R1-2501958 Discussion on AIML CSI compression TCL

R1-2501971 Discussion on AI/ML-based CSI compression CATT

R1-2502037 Views on UCI loss mitigation Ofinno

R1-2502073 Discussion CSI compression NEC

R1-2502096 Discussion on CSI Compression and other aspects of AIML Tejas Network Limited

R1-2502101 Study on CSI compression LG Electronics

R1-2502118 Discussion on CSI compression with AI/ML Fujitsu

R1-2502152 Discussion on AI/ML for CSI compression CMCC

R1-2502196 On AI/ML for CSI compression Lenovo

R1-2502213 Discussion on AI/ML for CSI compression Huawei, HiSilicon

R1-2502291 Additional study on AI/ML-based CSI compression OPPO

R1-2502338 On AI/ML-based CSI compression and other aspects InterDigital, Inc.

R1-2502355 Views on additional study for AI/ML based CSI compression Samsung

R1-2502433 Discussion on AI/ML model based CSI compression and other aspects on AI/ML model/data Xiaomi

R1-2502489 AI/ML for CSI feedback enhancement Mavenir

R1-2502492 Discussion on AI/ML for CSI compression Panasonic

R1-2502504 Discussion on AI/ML for CSI compression ETRI

R1-2502531 AI/ML for CSI Compression Nokia

R1-2502571 CSI compression and other aspects on AI/ML model/data Continental Automotive

R1-2502597 Discussion on AI based CSI compression and AI processing units Apple

R1-2502703 Additional study on AI/ML for NR air interface - CSI compression MediaTek Inc.

R1-2502758 Discussion on AI/ML for CSI compression NTT DOCOMO, INC.

R1-2502832 Additional study on CSI compression Qualcomm Incorporated

R1-2502912 Discussion on AI/ML for CSI Compression CEWiT

R1-2502934 Discussion on AI/ML-based CSI compression Pengcheng laboratory

R1-2502937 Discussion on AI/ML model-based CSI compression IIT Kanpur

R1-2503028 Summary#1 of Additional study on AI/ML for NR air interface: CSI compression and any other aspects on AI/ML model/data Moderator (Qualcomm)

From Monday session

Agreement

Introduce a dedicated AI/ML PU for AI/ML features for UE,

R1-2503029 Summary#2 of Additional study on AI/ML for NR air interface: CSI compression and any other aspects on AI/ML model/data Moderator (Qualcomm)

From Tuesday session

Agreement

For inter-vendor-collaboration Options 3a-1 and 4-1 in Direction A, confirm SGCS and NMSE as the type of performance metric that may be used for the performance target shared as additional information along with the exchanged dataset or the model parameters.

· FFS: when to use SGCS, NMSE, and which one to use or both, and relationship with the inter-vender collaboration sub-options.

· FFS: details of the format of the performance target

o Option 1: Average performance target, e.g. average SGCS and/or average NMSE.

o Option 2: distribution of the performance target, e.g., SGCS / NMSE for 5, 10, 20, 30 percentiles, etc.

· FFS: whether multiple performance targets should be exchanged for different configurations, such as antenna ports configuration, subband configuration and payload configuration, etc., along with each exchanged dataset or model parameters.

Agreement

In Options 3a-1 and 4-1, the exchanged dataset or the model parameters can be associated with an ID for pairing related discussion, then

· The same ID can be used for UE to collect UE-side target CSI for UE-side training

· The same ID can be used for applicability inquiry and reporting

· The same ID can be used for inference configuration

· The same ID can be used for NW-side data collection

· FFS: whether ID/even same ID is needed for monitoring configuration

· FFS: where the ID is assigned

· Note: whether the purpose for pair will be specified will be discussed separately.

Agreement

In Direction C, the fully standardized reference model is associated with an ID for pairing related discussion, then

· The same ID can be used for UE to collect UE-side target CSI for UE-side training

· The same ID can be used for applicability inquiry and reporting

· The same ID can be used for inference configuration

· The same ID can be used for NW-side data collection

· FFS: whether ID/even same ID is needed for monitoring configuration

· FFS: where the ID is assigned or how the ID is specified

· Note: whether the purpose for pair will be specified will be discussed separately.

Agreement

For inter-vendor collaboration Direction C,

· Use standardized quantization codebook.

For inter-vendor collaboration Direction A Options 4-1, 3a-1 (with or without NW-side target CSI sharing),

· Standardize configuration(s) of quantization codebook, e.g., scalar or vector quantization, segment size of VQ, codebook size.

o FFS: applicability of the above for Case 2

o Exchange quantization codebook of (the selected) standardized configuration(s) from NW-side to UE-side along with each exchanged dataset or model parameters.

· FFS: whether quantization codebook may be different across different payload size configurations.

R1-2503030 Summary#3 of Additional study on AI/ML for NR air interface: CSI compression and any other aspects on AI/ML model/data Moderator (Qualcomm)

From Wednesday session

Agreement

It is clarified that, for previous agreement on standardize configuration(s) of quantization for inter-vendor collaboration Direction A Options 4-1, 3a-1 (with or without NW-side target CSI sharing), resolve the first FFS with the following clarifications:

· The standardized quantization configuration(s) refers to the configuration(s) related to the dimensionality related to the quantization operation (e.g., e.g., scalar or vector quantization, segment size of VQ, codebook size) and does not preclude the use of more advanced quantization algorithms (e.g., using past samples).

· Exchanged quantization codebook does not preclude the use of codebook parameterized by parameters, e.g. quantization range and step size determined by some parameterized formula.

Conclusion

· For Direction C, confirm that the specified model should be trained using synthetic data (answer to issue 8).

· For inter-vendor collaboration option 3a-1 of Direction A, confirm that the specified model structure should be determined using synthetic data.

R1-2503031 Summary#4 of Additional study on AI/ML for NR air interface: CSI compression and any other aspects on AI/ML model/data Moderator (Qualcomm)

From Thursday session

Conclusion

· For Direction A Option 3a-1, based on evaluation results, RAN1 concludes that scalable model structure specification is feasible.

· For Direction C, based on evaluation results, RAN1 concludes that scalable model structure specification and model parameters specification is feasible.

o Note: RAN4 feasibility is a separate study to be confirmed by RAN4.

Conclusion

· RAN1 concludes that both Direction A and Direction C are feasible.

· RAN1 concludes that both sub-option 4-1 and sub-option 3a-1 are feasible.

o This includes both 3a-1 with and without target CSI sharing.

Conclusion

For NW-side monitoring with target CSI reporting

· Target CSI reporting via legacy CSI codebooks can be used for NW-side monitoring

· Target CSI reporting with CSI codebook enhancement via higher-resolution parameter combination may be beneficial for improving NW-side monitoring with additional cost of complexity and overhead at UE side.

R1-2503032 Summary#5 of Additional study on AI/ML for NR air interface: CSI compression and any other aspects on AI/ML model/data Moderator (Qualcomm)

From Friday session

Observations

For choice of token/feature dimension in the scalable model design, companies observe that there is small loss in SGCS for Case1 over Case2 under tokenization (Alt1, Alt3)

For layer1, under tokenization (Alt1),

8 sources [Qualcomm, CATT, Xiaomi, vivo, ZTE, Fujitsu, Samsung, Huawei] observe that average gain in SGCS of Case 1 over Case 2 is in the range of -3.34% to 0.33% with median value of -1.10%
2 sources [CATT, Xiaomi] observe average gain in SGCS of Case 1 (scalable structure) over benchmark [G1] is in the range of 2.04% to 7.84% with median value of 6.61%
3 sources [CATT, Xiaomi, Ericsson] observe average gain (%) in SGCS of Case 2 (scalable structure) over benchmark [G2] is in the range of 5.17% to 10.2% with median value of 10.1%

For layer1, under tokenization (Alt3),

1 source [vivo] observes average gain (%) in SGCS of Case 1 over Case 2 is in the range of -0.7% to 0.4% with median value of -0.3%
1 source [Ericsson] observes average gain (%) in SGCS of Case 2 (scalable structure) over benchmark [G2] is in the range of 5.4% to 6%

For scalability over the feature dimension, companies observe that there is small loss in SGCS for Case1 over Case2 assuming (Alt1, Alt2, Alt1+Alt2)

For layer1, under (Alt1),

4 sources [Qualcomm, CATT, Xiaomi, Fujitsu ] observes average gain (%) in SGCS of Case 1 over Case 2 is in the range of -3.34% to -0.4% with median value of -2.08%
2 sources [CATT, Xiaomi] observe average gain (%) in SGCS of Case 1 (scalable structure) over benchmark [G1] is in the range of 3% to 7.84% with median value of 6.71%
2 sources [CATT, Xiaomi] observe average gain (%) in SGCS of Case 2 (scalable structure) over benchmark [G2] is in the range of 5.17% to 10.2% with median value of 10.1%

For layer1, under (Alt2),

7 sources [Qualcomm, Xiaomi, vivo, ZTE, Fujitsu, Samsung, Huawei] observe average gain in SGCS of Case 1 over Case 2 is in the range of -3.2% to 0.1% with median value of -0.85%
1 source [Xiaomi] observes gain in SGCS of Case 1 (scalable structure) over benchmark [G1] is 2.04%
1 source [Xiaomi] observes gain (%) in SGCS of Case 2 (scalable structure) over benchmark [G2] is 5.17%

For layer1, under (Alt1+Alt2),

1 source [Qualcomm] observes average gain (%) in SGCS of Case 1 over Case 2 is in the range of -3.3% to -2.9% with median value of -3.1%.

For scalability over the token dimension, companies observe that there is small loss in SGCS for Case1 over Case2 assuming (Alt1, Alt2)

For layer1, under (Alt1),

2 sources [Qualcomm, vivo] observe average gain in SGCS of Case 1 over Case 2 is in the range of -3.2% to 0.9% with median value of -1.5%.

For layer1, under (Alt2),

3 sources [CATT, vivo, ZTE ] observe average gain in SGCS of Case 1 over Case 2 is in the range of -3.34% to 0.4% with median value of -0.75%.
1 source [CATT] observes average gain (%) in SGCS of Case 1 (scalable structure) over benchmark [G1] is in the range of 6.51% to 7.84% with median value of 6.87%
1 source [CATT] observes average gain (%) in SGCS of Case 2 (scalable structure) over benchmark [G2] is in the range of 10.12% to 10.2% with median value of 10.1%

For scalability over the payload configurations, companies observe that there is small loss in SGCS for Case1 over Case2 assuming (Alt1, Alt2)

For layer1, under (Alt1),

4 sources [Qualcomm, CATT, Xiaomi, Huawei] observe average gain (%) in SGCS of Case 1 over Case 2 is in the range of -0.73% to -3.34% with median value of -2.08%
2 sources [CATT, Xiaomi] observe average gain (%) in SGCS of Case 1 (scalable structure) over benchmark [G1] is in the range of 3% to 7.84% with median value of 6.71%
2 sources [CATT, Xiaomi] observe average gain (%) in SGCS of Case 2 (scalable structure) over benchmark [G2] is in the range of 5.17% to 10.2% with median value of 10.1%

For layer1, under (Alt2),

3 sources [Xiaomi, vivo, ZTE] observe average gain in SGCS of Case 1 over Case 2 is in the range of -3.2% to 0.4% with median value of -0.85%
1 source [Xiaomi] observes average gain (%) in SGCS of Case 1 (scalable structure) over benchmark [G1] is 2.04%
1 source [Xiaomi] observes average gain (%) in SGCS of Case 2 (scalable structure) over benchmark [G2] is 5.17%

For scalability over feature dimension, token dimension and payload configuration jointly,

For tokenization Alt1, feature scalability Alt1, token scalability Alt2 and payload scalability Alt1,

1 source [CATT] observes average gain in SGCS of Case 1 over case 2 is in the range of -3.34%~2.03% with median value of -2.93%
1 source [CATT] observes average gain (%) in SGCS of Case 1 (scalable structure) over benchmark [G1] is in the range of 6.51%~7.84%
1 source [CATT] observes average gain (%) in SGCS of Case 2 (scalable structure) over benchmark [G2] is in the range of 10.12%~10.23%

For tokenization Alt1, feature scalability Alt2, token scalability Alt2, payload configuration Alt2,

2 sources [ZTE, vivo] observe average gain in SGCS of Case 1 over case 2 is in the range of -2.8%~1.2% with median value of -1.2%, under same parameter set.
1 source [vivo] observes average gain in SGCS of Case 1 over Case 2 is in the range of -0.1% ~ 0.8% with median value of 0.1%, under different parameter set

For tokenization Alt1, feature scalability Alt2, token scalability Alt1, payload configuration Alt2,

· 1 source [vivo] observes average gain in SGCS of Case 1 over Case 2 is in the range of -1.7% ~ 5.4% with median value of -2.6%, under same parameter set

· 1 source [vivo] observes average gain in SGCS of Case 1 over Case 2 is in the range of -2.6% ~ 0% with median value of -0.9%, under different parameter set

For tokenization Alt1, feature scalability Alt1, payload configuration Alt1,

1 source [Xiaomi] observes average loss in SGCS of Case 1 over case 2 is in the range of -4.76%~-0.82% with median value of -2.08%.
1 source [Xiaomi] observes average gain (%) in SGCS of Case 1 (scalable structure) over benchmark [G1] is 3%
1 source [Xiaomi] observes average gain (%) in SGCS of Case 2 (scalable structure) over benchmark [G2] is 5.17%

For tokenization Alt1, feature scalability Alt2, payload configuration Alt2,

1 source [Xiaomi] observes average loss in SGCS of Case 1 over case 2 is in the range of -5.52%~-1.59% with median value of -2.96%.
1 source [Xiaomi] observes average gain (%) in SGCS of Case 1 (scalable structure) over benchmark [G1] is 2.04%
1 source [Xiaomi] observes average gain (%) in SGCS of Case 2 (scalable structure) over benchmark [G2] is 5.17%

For tokenization Alt1, feature scalability Alt2, token scalability Alt2,

1 source [ZTE] observes average gain in SGCS of Case 1 over case 2 is in the range of -0.4%~0.9% with median value of -0.23%.

For tokenization Alt3, token scalability Alt1, payload configuration Alt2,

· 1 source [vivo] observes average gain in SGCS of Case 1 over Case 2 is in the range of -2.1% ~ 1.6% with median value of -0.5%, under same parameter set

· 1 source [vivo] observes average gain in SGCS of Case 1 over Case 2 is in the range of -0.8% ~ 0% with median value of -0.4%, under different parameter set

Conclusion

UE-side monitoring is feasible.

Observation

Some companies think that, at least in some UE-side monitoring options, NW-side monitoring with target CSI reporting is needed to check the reliability of UE-side monitoring reports.

R1-2503034 Final summary of Additional study on AI/ML for NR air interface: CSI compression and any other aspects on AI/ML model/data Moderator (Qualcomm)

RAN1#121

9.1 Artificial Intelligence (AI)/Machine Learning (ML) for NR Air Interface

Please refer to RP-250792 for detailed scope of the WI.

R1-2504893 Session notes for 9.1 (AI/ML for NR Air Interface) Ad-Hoc Chair (CMCC)

Endorsed and incorporated below.

[121-R19-AI/ML] Email discussion on Rel-19 AI/ML – Taesang (Qualcomm)

- To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc

Post email discussion for TR finalization

R1-2504382 Rapporteur view on higher layer signalling of Rel-19 AI-ML for NR air interface Qualcomm Incorporated

R1-2504383 Draft TP to capture the output of Agenda Item 9.1.4.1 into TR Qualcomm Incorporated

9.1.1 Specification support for beam management

Agreement

For calculation the performance metric of Type 1 Option 2 performance monitoring for UE-sided model, when the size of the set for monitoring is smaller than the size of Set A,

· support the mapping of the resources in the set for monitoring to resources in Set A is configured via RRC, support

· A X-bit bitmap with Y non-zero bits is configured by the RRC in CSI Report Config for monitoring, where X is the size of Set A and Y is the size of the set for monitoring

o The x-th MSB of the bitmap corresponds to x-th resource in Set A

o The y-th nonzero bit of the bitmap corresponds to the y-th entry of associated nzp-CSI-RS-Resources or csi-SSB-ResourceList in the set for monitoring, 1≤y≤Y

Agreement

· At least for the monitoring Type 1 Option 2 of UE-side model monitoring, for calculation of metric for monitoring,

for BM-Case 1, the measurement result of n^th (n = 1,..,N) latest transmission occasion of the CSI-RS/SSB resources for monitoring is linked with an inference report, where the CSI reference resource of the corresponding inference report has the minimal slot offset to the n^th transmission occasion of the CSI-RS/SSB resources for monitoring.

o Wherein, the corresponding inference report, and the transmission occasion of the CSI-RS/SSB resources for monitoring are no later than the CSI reference resource corresponding to the CSI report for monitoring

Predefines a threshold X = 64 for the minimal slot offset, ~~which is configured by RRC,~~ where the minimal slot offset k is no larger than X; otherwise, the transmission occasion for monitoring has no linked inference report.

Note: CSI reference resource corresponding to the CSI report for monitoring and inference is determined based on legacy for all types (P/SP/AP) of CSI report carrying L1-RSRP, considering discussing associated timeline separately

· The associated working assumption made in RAN1#120b will not be confirmed.

Agreement

For data collection for UE-sided model, in CSI-report configuration, reportQuantity is set to “none-BM-r19”

Agreement

For UE-sided model, for inference report for BM-Case2, a time instance for prediction is defined as a slot.

Conclusion

• For NW sided model for L1-RSRP report in L1 signaling, legacy quantization steps and range are reused.

Agreement

For the determination of CSI report priority value of a CSI report for inference, the existing is reused

l k = 0 for the CSI report for inference

For the determination of CSI report priority value of a CSI report for monitoring, the existing is reused

l k = 0 for the CSI report for monitoring

Agreement

For UE-side model, for AI/ML based beam management for BM-Case 1 and BM-Case 2, for processing of a CSI report for inference,

· For PU occupancy, for the number of AI/ML PU (O_APU) and/or legacy CPU (O_CPU) are occupied,

· O_APU= 0 or X1/X2 is reported by UE in UE capability report for BM-Case 1 and BM-Case 2 respectively

· O_CPU=0 or Y1/Y2 is reported by UE in UE capability report for BM-Case 1 and BM-Case 2 respectively

· Note: Detailed values of X1/X2 and Y1/Y2 can be further discussed in UE feature.

· Note: Combination of O_APU= 0 and O_CPU=0 is not allowed

· Note: if any of the unoccupied PU cannot satisfy the corresponding required PU by the CSI report, the CSI report will follow the legacy behavior of exceeding the CPU limit, neither of the PUs are occupied

Agreement

For UE-sided model, regarding a CSI report with CSI-ReportConfig for inference for BM-Case1 and BM-Case 2, when applicable, extend legacy Z₃/Z₃’ to Z₃+d/ Z₃’+d’, where d and d’ are reported by UE per SCS for BM-Case 1 and BM-Case 2 respectively

· Detailed values of d and d’ can be further discussed in UE feature.

Agreement

For UE-sided model, regarding a CSI-ReportConfig for data collection,

· Reuse the existing CPU occupation time for a CSI report with CSI-ReportConfig with reportQuantity set to 'none' and TRS-info not configured

Agreement

For NW-sided model, for inference, when M<the size of measurement resource set, the beam information is CRI/SSBRI

Note: The purpose, such as above “For NW-sided model, for inference” will not be specified in RAN1 specifications.

Agreement

For UE-sided model, regarding a CSI report with CSI-ReportConfig for inference for BM-Case1,

· Rel-15 CPU occupation time is reused for CPU occupation time of the CSI report

· Rel-15 CPU occupation time is reused for AI/ML PU occupation time of the CSI report

· Note: this is applicable to all types of CSI reports (i.e., AP/SP/P CSI report)

Agreement

For beam prediction accuracy report for monitoring, the report quantity RS-PAI is (0 ≤≤ N)

· Where is the total count of accurate reference signal prediction instance(s) that meets the condition, among N latest transmission occasion(s) of monitoring resources that no later than CSI reference resource corresponding to the CSI report for monitoring

o condition:

§ for the transmission occasion of monitoring resources, it has a linked inference report

§ at least one of the nrofBestBeamforMonitoring-r19 identified CSI-RS resources, or SS/PBCH Block resources mapped to one of the nrofreportedpredictedrs-r19 reported P-CRI(s) or P-SSBRI(s), of the linked report of the CSI Reporting Setting for inference

o if this condition is met, the transmission occasion is counted as an accurate reference signal prediction instance; otherwise, it is not counted as an accurate reference signal prediction instance.

· Where N = 1, 3, 7, 15 is configured in CSI-ReportConfig

the size of CSI field associated with the RS-PAI is

Agreement

For BM-Case 1, one resource set for monitoring is configured in one CSI-ReportConfig for monitoring.

Agreement

For BM-Case 2, at least support to report one beam prediction accuracy for one configured time instance, configured by one CSI-ReportConfig for monitoring,

· only one resource set is configured in the CSI-ReportConfig

· the one configured time instance (i.e. f-th time instance of the time instance in one inference report) for metric calculation is configured in the CSI-ReportConfig for monitoring

· the performance metric of the f-th time instance is calculated based on N latest transmission occasion(s) of monitoring resource, no later than CSI reference resource corresponding to the CSI report for monitoring

The measurement result of n^th (n = 1,..,N) latest transmission occasion of the CSI-RS/SSB resources for monitoring is linked with the f-th time instance for prediction, where the f-th time instance has the minimal slot offset to the n^th transmission occasion of the CSI-RS/SSB resources for monitoring.

o Wherein, the corresponding inference reports, and the transmission occasions of the CSI-RS/SSB resources for monitoring, are no later than the CSI reference resource corresponding to the CSI report for monitoring

Predefines a threshold X =64, where the minimal slot offset k is no larger than X; otherwise, the transmission occasion for monitoring has no linked time instance.

Note: CSI reference resource corresponding to the CSI report for monitoring is determined based on legacy for all types (P/SP/AP) of CSI report carrying L1-RSRP

The associated working assumption made in RAN1#120b will not be confirmed.

Agreement (Made in RAN1#119)

• In Step 3, following configurations are provided from NW to UE:

o UE is allowed to do UAI reporting via OtherConfig,

o The applicability report is based on A) and/or B)

§ It is up to RAN 2 to design the container

§ A) one or more of CSI-ReportConfig for inference configuration (wherein the associated ID may be configured in CSI framework as working assumption applied)

· Note: CSI report configuration for UE-side model inference can’t be activated immediately upon receiving Step 3

§ B) One set or multiple sets of inference related parameters for applicability report only (not for inference)

· It is up to RAN2 to design the container.

· The set of inference related parameters selected from the IEs in/or the IEs referred by CSI-ReportConfig as a starting point, e.g.,

o the associated ID

§ Note: this doesn’t imply the associated ID is mandatory

o Set A related information

o Set B related information

o Report content related information

o For BM-Case 2,

§ Time instances related information for measurements

§ Time instances related information for prediction

• In Step 4, UE reports applicability for all the above A) one or more CSI-ReportConfig and/or B) set(s) of inference related parameters

o FFS on whether/what other information along with the applicability is needed

o If A) is configured in Step 3,

§ Applicable aperiodic CSI Report and semi-persistent CSI report can be activated/triggered by NW after the applicability reported.

§ Applicable periodic CSI Report is considered as activated only if the applicability of the corresponding CSI-ReportConfig is reported in RRCReconfigurationComplete.

o Note: Step 5 may be optional if UE has already been configured with CSI-ReportConfig in Step 3

Agreement

For UE-sided model, for BM-Case 1 and BM-Case 2, for content in the report of inference results, for Opt 1 (only beam information of predicted Top K beam(s)), the ranking information of the predicted Top K beams for K > 1 is conveyed by the order of the beam information.

Agreement

For UE-sided model, regarding a CSI report with CSI-ReportConfig for inference for BM-Case2, for occupancy duration of CPU and APU, same occupation time for AI/ML PU and legacy CPU.

· If the CSI report is aperiodic, for AI/ML PU, and for CPU, Rel-15 CPU occupation time for AP CSI report is reused

· If the CSI report is semi-persistent or periodic,

· From the 1st symbol of the latest CSI-RS/SSB transmission occasion no later than CSI reference resource, until the last symbol of the PUCCH/PUSCH carrying the report.

Agreement

For option B of applicability check, RAN 1 assumes that at least the following RRC parameters are to be reused:

· For both BM-Case 1 and BM-Case 2:

o associatedIDforSetA-r19, resourcesForSetA-r19, resourcesForChannelMeasurement, associatedIDforSetB-r19, reportQuantity-r19, reportConfigType, nrofreportedpredictedrs-r19

· For BM-Case 2:

o TimeGap-r19, nroftimeinstance-r19,

· Note: this doesn’t imply the associated ID is always present

R1-2504772 FL summary #3 for AI/ML in beam management Samsung (Moderator)

R1-2504771 FL summary #2 for AI/ML in beam management Samsung (Moderator)

R1-2504770 FL summary #1 for AI/ML in beam management Samsung (Moderator)

R1-2504769 FL summary #0 for AI/ML in beam management Samsung (Moderator)

R1-2503230 Discussion on specification support for AI/ML-based beam management FUTUREWEI

R1-2503251 Discussion on AIML for beam management Huawei, HiSilicon

R1-2503298 Specification Support for AI/ML in Beam Management Kyocera

R1-2503347 Remaining issues on specification support for beam management vivo

R1-2503432 AI/ML for beam management Ericsson

R1-2503505 Discussion on AIML for beam management Spreadtrum, UNISOC

R1-2503550 Discussion for supporting AI/ML based beam management Samsung

R1-2503627 Discussion on AIML beam management TCL

R1-2503648 Discussion on AI/ML-based beam management ZTE Corporation, Sanechips

R1-2503709 Discussion on AI/ML-based beam management Tejas Network Limited

R1-2503727 Discussion on AI/ML for beam management Ofinno

R1-2503757 Discussion on Specification Support of AI/ML for Beam Management Indian Institute of Tech (M), IIT Kanpur

R1-2503770 Discussion on AI/ML-based beam management CATT

R1-2503820 Discussion on specification support for beam management CMCC

R1-2503872 Discussion on AI/ML for beam management Xiaomi

R1-2503927 Discussion on specification support for beam management NEC

R1-2503950 Discussion on specification support for beam management Ruijie Networks Co. Ltd

R1-2503963 Discussion on AI/ML for beam management InterDigital, Inc.

R1-2503981 Discussions on AI/ML for beam management LG Electronics

R1-2503987 Discussion on specification support for beam management Panasonic

R1-2503996 Specification support for AI-enabled beam management NVIDIA

R1-2504024 AI/ML based Beam Management Google

R1-2504039 AI/ML specification support for beam management Lenovo

R1-2504043 Discussion on AI/ML for beam management China Telecom

R1-2504058 Discussion on specification support for beam management Sony

R1-2504080 Discussion on specification support on AI/ML for beam management Fujitsu

R1-2504093 Discussion on AI/ML for beam management HONOR

R1-2504112 AI/ML for Beam Management Nokia

R1-2504116 Discussion on AI/ML based beam management Hyundai Motor Company

R1-2504129 Discussion on specification support for beam management ETRI

R1-2504171 Discussion on specification support for AI/ML beam management Transsion Holdings

R1-2504183 Specification support for beam management KDDI Corporation (TTC)

R1-2504223 On specification for AI/ML-based beam management OPPO

R1-2504258 Discussion on specification support for AIML-based beam management MediaTek Inc.

R1-2504308 AI/Ml based beam management Apple

R1-2504384 Specification support for AI-ML-based beam management Qualcomm Incorporated

R1-2504464 Discussions on specification support for beam management Sharp

R1-2504491 Discussion on AI/ML for beam management NTT DOCOMO, INC.

R1-2504541 Discussion on AI/ML based beam management KT Corp.

R1-2504560 Specification support for beam management Fraunhofer HHI, Fraunhofer IIS

R1-2504571 Discussion on AIML based beam management ASUSTeK

R1-2504592 On Performance Monitoring for Beam Management Use Case NTU

R1-2504625 Specification support for AI/ML beam management ITL

9.1.2 Specification support for positioning accuracy enhancement

Agreement

For Case 3a, the FFS in RAN1#118bis agreement is resolved by updating the agreement as follows.

Agreement (RAN1#118bis)

· (Mandatory) timing information;

· (Optional) Quality of the timing information;

o Existing IE “Timing Measurement Quality” can be reused.

· (Mandatory) Time stamp.

· ~~FFS: LOS/NLOS indicator.~~

· (Optional) LOS/NLOS indicator with legacy format

Note: The final decision of “mandatory” or “optional” presence of each field is up to RAN3.

Note: It is up to RAN3 to decide whether the field of LOS/NLOS indicator should be removed or kept.

Agreement

On top of the RAN1#118bis agreement,

Agreement (RAN1#118bis)

For training data collection of AI/ML based positioning, the quality indicator of timing information in Part A when reported is:

· When applicable, the existing IE for timing quality, i.e., NR-TimingQuality in 37.355 and IE “Timing Measurement Quality” in 38.455;

o FFS: details on how to associate quality indicator to timing information

Further conclude that for case 3b, no separate quality indicator for power information is introduced if the channel measurement includes power information in addition to the timing information.

Agreement

• For AI/ML based positioning Case 3a, when Part B is provided to the gNB from LMF, regarding the time stamp of Part B:

• Existing IE “Time Stamp” in TS 38.455 can be reused from RAN1 perspective.

Agreement

For AI/ML based positioning in Case 3b, if Part B is sent via LPP from UE to LMF, the time stamp of Part B follows the legacy IE measurementReferenceTime-r16, i.e., it is up to UE to make a choice between the following two:

• NR-TimeStamp

• UTCTime

Conclusion

For measurement report of AI/ML assisted positioning Case 3a, when timing information is reported from gNB to LMF,

• From RAN1 perspective, LMF shall be able to distinguish whether the timing information is pre Rel-19 legacy timing measurement or Rel-19 Case 3a timing measurement.

• It is up to RAN3 to decide how to ensure that LMF can distinguish between the two types of timing measurement.

Working Assumption

For AI/ML based positioning Case 1, regarding info #7 in the assistance information from legacy UE-based DL-TDOA, it can be provided as in legacy UE-based DL-TDOA or implicitly.

Agreement

Above Working Assumption is confirmed.

Agreement

“FFS: N_t” in RAN1#120 agreement is resolved by adopting the following:

· Regarding measurement parameters, for measurement report of type (B) Rel-19 enhanced measurement, the measurement parameters does not include N_t.

Agreement

The FFS in RAN1#116bis agreements is addressed by updating the agreement as follows:

Agreement (RAN1#116bis)

~~FFS: whether it is applicable when Case 3b is used to support multi-RTT~~

Agreement

For AI/ML positioning Case 3b, for gNB channel measurements reported to LMF, regarding the power information (if included),

· reuse the existing measurement report mapping table for SRS-RSRPP in 38.133.

Agreement

For AI/ML based positioning Case 3b, regarding the time stamp in a measurement report from gNB to LMF,

· existing IE “Time Stamp” in TS 38.455 can be reused from RAN1 perspective.

Conclusion

For training data collection of AI/ML based positioning Case 3b, from RAN1 perspective, if the label data of location is generated by UE and transferred from UE to LMF, label and quality indicator of label can be provided by reusing existing IEs, legacy procedure, and legacy UE capability.

• From RAN1 perspective, the existing IE can use one of the geographic shapes defined in TS 23.032. The location estimate uncertainty and confidence (if included with the geographic shapes) can serve as quality indicator of the label.

Conclusion

For model performance monitoring of AI/ML positioning Case 1, for model performance monitoring metric calculation in label-based model monitoring,

· There is no consensus in RAN1 to support Option B (including Option B-1 and B-2).

Agreement

The FFS in the RAN1#118bis agreement is resolved by updating the agreement as follows.

Agreement (RAN1#118bis)

For training data collection of AI/ML based positioning, the quality indicator of timing information in Part A when reported is:

· When applicable, the existing IE for timing quality, i.e., NR-TimingQuality in 37.355 and IE “Timing Measurement Quality” in 38.455;

o ~~FFS: details on how to associate quality indicator to timing information~~

· For type (A) path-based measurement, the existing IE for timing quality is provided as in legacy signaling (i.e., per-path).

· For type (B) Rel-19 enhanced measurement, one existing IE for timing quality is used to indicate the quality of the reported timing information.

Agreement

For AI/ML based positioning Case 1, regarding Info #7 in the assistance information from legacy UE-based DL-TDOA,

· If implicitly provided, the implicit indication of Info #7 is via associated ID.

o For given TRP(s), same associated ID implies that geographical coordinates of the TRP(s) can be understood as consistent by the UE.

o The associated ID is not expected to provide the real value of Info #7 (i.e., geographical coordinates of the TRP(s) are not disclosed).

o an associated ID is configured per-cell (e.g., NCGI-r15)

§ UE does not expect to receive different values of associated ID for TRPs belonging to the same NCGI-r15

o Associated ID can be realized by an identifier of N bits (e.g., 8 bits)

Conclusion

For Rel-19 AI/ML based positioning, there is no consensus in RAN1 to introduce further enhancement to the existing phase measurement.

· From the RAN1 perspective, LMF may use a measurement report from legacy method for carrier phase positioning in generating model input, based on LMF implementation.

Agreement

The FFS in the RAN1#118bis agreement is resolved by adopting the following:

Agreement (RAN1#118bis)

From RAN1 perspective, for model inference of AI/ML positioning Case 3b, at least the following are mandatorily or optionally supported in a measurement report from gNB to LMF:

· (Mandatory) Channel measurement;

· (Optional) Quality of the channel measurement;

o ~~FFS: details of the quality~~

o The quality indicator of timing information reuses IE “Timing Measurement Quality” in 38.455.

§ For type (A) path-based measurement, the IE “Timing Measurement Quality” is provided as in legacy signaling (i.e., per-path).

§ For type (B) Rel-19 enhanced measurement, one IE “Timing Measurement Quality” is used to indicate the quality of the reported timing information.

o No separate quality indicator for power information is introduced if the channel measurement includes power information in addition to timing information.

· (Mandatory) Time stamp of the channel measurement.

R1-2504695 Summary #5 of specification support for positioning accuracy enhancement Moderator (Ericsson)

R1-2504694 Summary #4 of specification support for positioning accuracy enhancement Moderator (Ericsson)

R1-2504693 Summary #3 of specification support for positioning accuracy enhancement Moderator (Ericsson)

R1-2504692 Summary #2 of specification support for positioning accuracy enhancement Moderator (Ericsson)

R1-2504691 Summary #1 of specification support for positioning accuracy enhancement Moderator (Ericsson)

R1-2503238 AI/ML for Positioning Accuracy Enhancement Ericsson

R1-2503252 Discussion on AI/ML for positioning accuracy enhancement Huawei, HiSilicon

R1-2503348 Remaining issues on specification support for positioning accuracy enhancement vivo

R1-2503506 Discussion on AIML for positioning accuracy enhancement Spreadtrum, UNISOC

R1-2503551 Discussion for supporting AI/ML based positioning accuracy enhancement Samsung

R1-2503649 Discussion on AI/ML-based positioning enhancement ZTE Corporation, Pengcheng Laboratory

R1-2503719 Discussion on AI/ML for positioning accuracy enhancement Tejas Network Limited

R1-2503750 Remaining issues on specification support for positioning accuracy enhancement TCL

R1-2503751 Discussion on support for AIML positioning InterDigital, Inc.

R1-2503771 Discussion on AI/ML-based positioning CATT, CICTCI

R1-2503811 AI/ML positioning accuracy enhancement Fraunhofer IIS, Fraunhofer HHI

R1-2503821 Discussion on specification support for positioning accuracy enhancement CMCC

R1-2503873 Discussion on AI/ML-based positioning accuracy enhancement Xiaomi

R1-2503921 Discussion on specification support for AIML based positioning accuracy enhancement NEC

R1-2503951 Discussion on specification support for positioning accuracy enhancement Ruijie Networks Co. Ltd

R1-2503997 Specification support for AI-enabled positioning NVIDIA

R1-2504025 AI/ML based Positioning Google

R1-2504040 Specification impacts for AI/ML positioning Lenovo

R1-2504059 On supporting AI/ML based positioning accuracy enhancement Sony

R1-2504081 Discussion on specification support for AIML-based positioning accuracy enhancement Fujitsu

R1-2504113 AI/ML for Positioning Accuracy Enhancement Nokia

R1-2504130 Discussion on specification support for positioning accuracy enhancement ETRI

R1-2504224 On specification for AI/ML-based positioning accuracy enhancements OPPO

R1-2504285 Discussion on Specification Support of AI/ML for Positioning Accuracy Enhancement Indian Institute of Tech (M)

R1-2504309 Specification Support for AI/ML-based positioning Apple

R1-2504385 Specification support for AI-ML-based positioning accuracy enhancement Qualcomm Incorporated

R1-2504465 Discussion on specification support for AI/ML based positioning accuracy enhancements Sharp

R1-2504492 Discussion on AI/ML for positioning accuracy enhancement NTT DOCOMO, INC.

R1-2504570 Design for AI/ML based positioning MediaTek Korea Inc.

R1-2504580 Discussions on specification support for positioning accuracy enhancement for AI/ML ITL

R1-2504596 Discussion on specification support for AI/ML positioning accuracy enhancement CEWiT

9.1.3 Specification support for CSI prediction

Agreement

For CSI prediction using UE-side model, for data collection for training, reportQuantity is set to ‘none-CSI-r19’.

Agreement

For CSI prediction using UE-side model, to calculate the inference report using Doppler codebook,

· For PU occupancy, support

o Dedicated AI/ML PU (O_APU) and/or legacy CPU (O_CPU) are occupied,

- O_APU= 0 or N is reported by UE

- O_CPU=0 or M is reported by UE

- Note: Detailed values of N and M can be further discussed in UE feature.

- Note: Combination of O_APU= 0 and O_CPU=0 is not allowed

- Note: if any of the unoccupied PU cannot satisfy the corresponding required PU by the CSI report, the CSI report will follow the legacy behaviour of exceeding the CPU limit, neither of the PUs are occupied

· For occupancy duration of CPU and APU,

o the same occupancy duration is used if both CPU and APU are reported non-zero value

o if associated monitoring report is not configured, reuse following legacy occupancy duration

- For semi-persistent CSI report on PUSCH with P/SP CSIRS CMR, occupation starts from the first symbol of K_P-th latest consecutive P/SP-CSI-RS occasions no later than CSI reference resource, until the last symbol of the PUSCH carrying the report, where K_Pis indicated by UE capability.

l Note: Detailed values of K_P can be further discussed in UE feature.

- Aperiodic CSI report occupies PU(s) from the first symbol after the PDCCH triggering the CSI report until the last symbol of the scheduled PUSCH carrying the report.

· The total number of dedicated AI/ML PU for AI/ML is reported by UE capability

Agreement

For CSI prediction using UE-side model, for inference, regarding active resource/port counting,

- Reuse legacy active resource/port counting at least if associated monitoring report is not configured

Agreement

For CSI prediction using UE-side model, for inference, in addition to legacy Z/Z’ for doppler codebook, UE may report the value of t per SCS

- Detailed value of t can be discussed in UE feature

Agreement

For CSI prediction using UE-side model, for UE assisted performance monitoring,

- Support to reuse CSI framework for the configuration for monitoring result report in L1 signaling

o Dedicated resource set for monitoring and report configuration for monitoring are configured in a dedicated CSI report configuration used for monitoring

§ The ID of an inference report configuration is configured in the configuration for monitoring to link the inference report configuration and monitoring report configuration

§ For monitoring report type, semi-persistent and aperiodic are supported

§ The following combination for inference report type and monitoring report type are supported

Monitoring report type

Inference report type

SP report

AP report

Not support

Support

SP report

Support

o For monitoring resource type for measurement, periodic, semi-persistent and aperiodic are supported.

Agreement

· For CSI prediction using UE-side model, for UE assisted performance monitoring,

- If the inference measurement resource is aperiodic CSI-RS, UE is expected to receive the monitoring report trigger, if any, no later than the first symbol of the earliest occasion of K inference measurement resources that are no later than the CSI reference resource of the associated inference report;

o Additional active resource/port counting time for the aperiodic resource of the inference report is from the end of the inference report to the end of the triggered monitoring report

- If inference report is aperiodic and the inference measurement resource is periodic or semi-persistent, UE is expected to receive the monitoring report trigger, if any, no later than the first symbol of the earliest occasion of the most recent Kp inference measurement resource transmission occasions that are no later than the CSI reference resource of the associated inference report

Agreement

For CSI prediction using UE-side model, for data collection for training,

- O_CPU=1

- the CPU occupancy starts from the first symbol of each P/SP-CSI-RS occasion till Z3’ symbols after the P/SP-CSI-RS occasion.

Agreement

For CSI prediction using UE-side model, for reporting contents of UE assisted performance monitoring,

- one SGCS is calculated based on predicted CSI for one inference reporting, and ground truth CSI, another SGCS is based on ground truth CSI and CSI (non-predicted) corresponding to the latest CSI-RS transmission occasion not later than CSI reference resource of the inference reporting instance

- SGCS is reported

o wideband frequency granularity

o only for one prediction instance configured by NW

o per layer, and the total number of layers is the same as the reported RI in the associated inference report

- Introduce new RRC parameter for reportQuantity, e.g., ‘SGCS-r19’

- Each SGCS value is quantized with 4-bit

o 15 codepoints are used to uniformly quantize in range [0.3 1] in linear scale.

o One codepoint is used to indicate the value range of (0 0.3]

- Only one monitoring resource set is configured in the CSI-ReportConfig

- The one configured time instance (i.e. f-th doppler domain unit in one inference report) for SGCS calculation is configured in the CSI-ReportConfig for monitoring, for N4>1

Agreement

For CSI prediction using UE-side model, support single UCI part with the following report format (i.e., CSI field mapping order) among a set of SGCSs.

SGCS₁ #1

SGCS₁ #2

…

SGCS₁ #v

SGCS₂ #1

SGCS₂ #2

…

SGCS₂ #v

- SGCS₁is calculated based on predicted CSI for one inference reporting, and ground truth CSI,

- SGCS₂is based on ground truth CSI and CSI (non-predicted) corresponding to the latest CSI-RS transmission occasion not later than CSI reference resource of the inference reporting instance

- SGCS_i #k is the SGCS of k-th layer of i-th SGCS where k ={1, …., v}, and i ={1, 2}.

- v is the value of the reported RI in the associated inference report.

R1-2504778 Summary #4 of CSI prediction Moderator (LG Electronics)

R1-2504777 Summary #3 of CSI prediction Moderator (LG Electronics)

R1-2504775 Summary #2 of CSI prediction Moderator (LG Electronics)

R1-2504774 Summary #1 of CSI prediction Moderator (LG Electronics)

R1-2503232 Discussion on CSI Processing Unit for AI/ML-based CSI prediction FUTUREWEI

R1-2503246 AI/ML for CSI prediction Ericsson

R1-2503253 Discussion on AIML for CSI prediction Huawei, HiSilicon

R1-2503349 Remaining issues on specification support for CSI prediction vivo

R1-2503448 Discussion on AI-based CSI prediction TCL

R1-2503507 Discussion on AIML for CSI prediction Spreadtrum, UNISOC

R1-2503552 Views on AI/ML based CSI prediction Samsung

R1-2503650 Discussion on specification support for AI CSI prediction ZTE Corporation, Sanechips

R1-2503749 Specification support for CSI prediction Quectel

R1-2503772 Discussion on AI/ML-based CSI prediction CATT

R1-2503822 Discussion on AI/ML for CSI prediction CMCC

R1-2503874 Further discussion on remained issues for AI/ML model based CSI prediction Xiaomi

R1-2503922 Discussion on specification support for CSI prediction NEC

R1-2503952 Discussion on specification support for CSI prediction Ruijie Networks Co. Ltd

R1-2503976 On AI/ML-based CSI prediction InterDigital, Inc.

R1-2503982 Discussions on CSI prediction LG Electronics

R1-2503988 Discussion on AI/ML-based CSI prediction Panasonic

R1-2503998 Specification support for AI-enabled CSI prediction NVIDIA

R1-2504026 AI/ML based CSI Prediction Google

R1-2504041 Specification support for CSI prediction Lenovo

R1-2504060 Specification support for UE-side AI/ML CSI prediction model monitoring Sony

R1-2504082 Discussion on specification support for CSI prediction Fujitsu

R1-2504094 Discussion on AI/ML for CSI prediction HONOR

R1-2504114 AI/ML for CSI Prediction Nokia

R1-2504131 Discussion on specification support for CSI prediction ETRI

R1-2504225 On specification for AI/ML-based CSI prediction OPPO

R1-2504259 AI/ML - Specification support for CSI Prediction MediaTek Inc.

R1-2504310 Discussion on AI based CSI prediction Apple

R1-2504386 Specification support for CSI prediction Qualcomm Incorporated

R1-2504466 Discussion on specification support for AI/ML based CSI prediction Sharp

R1-2504493 Discussion on AI/ML for CSI prediction NTT DOCOMO, INC.

R1-2504597 Discussion on specification support for CSI prediction CEWiT

R1-2504649 Discussion on AI/ML CSI prediction Continental Automotive

9.1.4 Additional study on AI/ML for NR air interface

Please refer to RP-250308 for detailed scope of the SI on AI/ML for NR air interface.

9.1.4.11 CSI compression

Including any remaining discussions on “Processing Unit”.

Observation

• The model structure(s) for the reference encoder in inter-vendor collaboration sub-option 3a-1 can be same as/equivalent to the structure of the RAN4 defined/specified (if defined/specified for testability) reference encoder.

· To reduce the workload of the potential normative work scope, the model structure(s) for the reference encoder in inter-vendor collaboration sub-option 3a-1 is(are) same as/equivalent to the structure of the RAN4 defined/specified (if defined/specified for testability) reference encoder.

Agreement

For addressing inter-vendor collaboration complexity, RAN1 identifies the following specification impacts for supporting sub-option 3a-1 (including with target CSI and without target CSI), sub-option 4-1, and Direction C

Reference model / structure specification (for sub-option 3a-1 and Direction C)

Note: The so called fully specified reference model discussed in RAN1 for Direction C is assumed to be equivalent to the to-be-specified model, if specified, for performance requirements in RAN4.
Note: The model structure(s) for the reference encoder in inter-vendor collaboration sub-option 3a-1 can be same as/equivalent to the structure of the RAN4 defined/specified (if defined/specified for testability) reference encoder.

To reduce the workload of the potential normative work scope, the model structure(s) for the reference encoder in inter-vendor collaboration sub-option 3a-1 is(are) same as/equivalent to the structure of the RAN4 defined/specified (if defined/specified for testability) reference encoder.

Note: RAN1 has studied and agreed on a scalable model structure for feasibility study during Rel-19 study, and considers that can serve as a starting point for the model structure specification for the potential normative work.

Format and contents of parameter/dataset/information exchange: dataset (for 4-1 and 3a-1 with target CSI)/ encoder parameter (for 3a-1) / additional information (for 3a-1 and 4-1).
The workload can be reduced by identifying the common part among different aspects.

Observation

Case 0, encoder complexity (FLOPs) vs. SGCS gain (%)

A graph with many colored dots

AI-generated content may be incorrect.

A graph with different colored dots

AI-generated content may be incorrect.

A graph with red and blue dots

AI-generated content may be incorrect.

For temporal domain Case 0, the results on trade-off between complexity (FLOPs) and SGCS gain (%) over benchmark are summarized as follows

· For using spatial-frequency domain eigen-vector as input,

o For layer 1 and payload size X-bin:

§ 9 sources [QC, CATT, vivo, Futurewei, OPPO, LG, Fujitsu, IITM, PengCheng Lab] observe minor to significant performance gain of 2.8%~20.68% over benchmark for FLOPs range of 1M to 10M.

§ 11 sources [QC, CATT, vivo, Futurewei, Ericsson, Samsung, OPPO, LG, Fujitsu, PengCheng Lab, Spreadtrum] observes minor to significant performance gain of 1.2% ~21.7% over benchmark for FLOPs range of 10M to 100M.

§ 5 sources [~~vivo~~, Huawei, Xiaomi, Spreadtrum, Nokia, OPPO] observe minor to significant performance gain of 4.8%~13.5% over benchmark for FLOPs > 100M

o For layer 1 and payload size Y-bin:

§ 3 sources [CATT, LG, Vivo] observe minor to significant performance gain of -1.8%~10.45% over benchmark for FLOPs range of 1M to 10M.

§ 4 sources [CATT, LG, Vivo, Nokia] observe minor to significant performance gain of 0.4%~11.45% over benchmark for FLOPs range of 10M to 100M.

§ 2 sources [Xiaomi, Nokia] observe minor to moderate performance gain of 1.63%~6.1% over benchmark for FLOPs > 100M

o For layer 1 and payload size Z-bin:

§ 2 sources [CATT, LG] observe minor to significant performance gain of -3.32%~10.62% over benchmark for FLOPs range of 1M to 10M.

§ 2 sources [CATT, LG] observe minor to significant performance gain of 1.2%~11.99% over benchmark for FLOPs range of 10M to 100M.

§ 2 sources [Xiaomi, Nokia] observe minor performance gain of -2.05%~2.1% over benchmark for FLOPs > 100M

· For using angle-delay domain eigen-vector as input

o For layer 1 and payload size X-bin:

§ 2 sources [Ericsson, Samsung] observe minor to significant performance gain of 2.8%~19.29% over benchmark when FLOPs < 1M.

§ 3 sources [Ericsson, QC, Vivo] observe minor to moderate performance gain of 1.4%~6.63% over benchmark for FLOPs range from 1M to 10M.

§ 2 sources [Ericsson, QC] observe moderate performance gain of 5.3%~6.8% over benchmark for FLOPs > 10M.

· For using spatial-frequency domain channel matrix as input

o For layer 1 and payload size X-bin:

§ 1 source [Huawei] observes 37.8% performance gain over benchmark when FLOPs is 100M.

Case 0, encoder model size (# parameters) vs. SGCS gain (%)

A chart with many colored dots

AI-generated content may be incorrect.

A graph with numbers and symbols

AI-generated content may be incorrect.

For temporal domain Case 0, the results on trade-off between model size (# parameters) and SGCS gain (%) over benchmark are summarized as follows

· For using spatial-frequency domain eigen-vector as input,

o For layer 1 and payload size X-bin:

§ 10 sources [QC, CATT, vivo, Futurewei, Ericsson, OPPO, LG, Fujitsu, PengCheng Lab, IITM] observe minor to significant performance gain of 1.2%~18.5% over benchmark for model size less than 1M parameters.

§ 12 sources [CATT, vivo, Futurewei, Ericsson, Xiaomi, OPPO, LG, Fujitsu, PengCheng Lab, IITM, Spreadtrum, Nokia] observe minor to significant performance gain of 1.3% ~21.7% over benchmark for model size in range of 1M to 10M parameters.

§ 4 sources [Samsung, Huawei, OPPO, Spreadtrum] observe significant performance gain of 10.7%~27.9% over benchmark for model size > 10M parameters

o For layer 1 and payload size Y-bin:

§ 4 sources [CATT, LG, Vivo, Nokia] observe minor to significant performance gain of -1.8%~10.45% over benchmark for model size less than 1M parameters.

§ 5 sources [CATT, LG, Vivo, Nokia, Xiaomi] observe minor to significant performance gain of 1.63% ~11.45% over benchmark for model size in range of 1M to 10M parameters.

o For layer 1 and payload size Z-bin:

§ 2 sources [CATT, LG] observe minor to significant performance gain of -3.32%~10.62% over benchmark for model size less than 1M parameters.

§ 4 sources [CATT, LG, Nokia, Xiaomi] observe minor to significant performance gain of -2.05% ~11.99% over benchmark for model size in range of 1M to 10M parameters.

· For using angle-delay domain eigen-vector as input,

o For layer 1 and payload size X-bin:

§ 4 sources [Ericsson, Samsung, QC, Vivo] observe minor to significant performance gain of 1.4%~19.29% over benchmark when model size < 1M parameters.

§ 1 source [Ericsson] observe moderate performance gain of 6.5%~6.8% over benchmark for model size in range of 1M to 10M parameters.

· For using spatial-frequency domain channel matrix as input,

o For layer 1 and payload size X-bin:

§ 1 source [Huawei] observes 37.8% performance gain over benchmark when model size is 12M params

Case 0, decoder complexity and model size

In most companies’ results, the encoder and the decoder have similar complexity, as shown in the following plots. Therefore, the performance-complexity trade-off for the decoder should be similar to that of the encoder.

A graph with orange dots

AI-generated content may be incorrect.

A graph of a graph

AI-generated content may be incorrect.

Case 0, comparison of Rel-18 evaluations and Rel-19 evaluations

The following plot shows the SGCS gain vs. encoder FLOPs, comparing the numbers from CSI_Table 1 (Rel-18) and the numbers from CSI_Table X9 (Rel-19).

A graph with red and blue dots

AI-generated content may be incorrect.

It is observed that the performance/complexity trade-off has improved in Rel-19 compared to Rel-18 evaluations.

In summary,

· For temporal domain Case 0, most of the SGCS gain is achievable using an encoder model with complexity less than 10M FLOPs. Use of more complex models provides limited additional SGCS gain. Similar trends are observed for the decoder complexity.

· For temporal domain Case 0, most of the SGCS gain is achievable using an encoder model with size less than 1M parameters. Use of larger models provides marginal performance improvements. Similar trends are observed for the decoder model size.

· For temporal domain Case 0, compared to Rel-18 evaluations, Rel-19 evaluations show improved performance/complexity trade-off.

o Reasons for the improved performance/complexity trade-off include the use more optimized AI/ML model structures and the use of different inputs.

Observation

Case 2, model complexity (FLOPs) vs. SGCS gain (%)

A graph of different colored squares

AI-generated content may be incorrect.

For temporal domain Case 2, the results on trade-off between complexity (FLOPs) and SGCS gain (%) over benchmark are summarized as follows

· For layer1,

o 5 sources [Samsung, CATT, LG, QC, Vivo] observe minor to significant performance gain of 3.4%~20% over benchmark when FLOPs <= 10M.

o 6 sources [ZTE, Apple, QC, Fujitsu, LG, Nokia] observe moderate to significant performance gain of 4.11%~28% over benchmark when 10M< FLOPs <= 100M.

o 8 sources [Nokia, OPPO, CMCC, Xiaomi, FW, Spreadtrum, ETRI, HW~~, Nokia~~] observe moderate to significant performance gain of 4%~27.8% over benchmark when FLOPs > 100M.

where the complexity (FLOPs) is the average of the encoder FLOPs and the decoder FLOPs.

Case 2, model size (# parameters) vs. SGCS gain (%)

A graph of different colored squares

AI-generated content may be incorrect.

For temporal domain Case 2, the results on trade-off between model size (# parameters) and SGCS gain (%) over benchmark are summarized as follows

· For layer1,

o 6 sources [QC, ZTE, Vivo, LG, CATT, Nokia] observe minor to significant performance gain of 3.4%~27.9% over benchmark when model size <= 1M parameters.

o 9 sources [Apple, Fujitsu, LG, Nokia, CMCC, Xiaomi, HW, ETRI, FW~~, Nokia~~] observe moderate to significant performance gain of 4%~27.8% over benchmark when 1M< model size <= 10M parameters.

o 2 sources [Spreadtrum, OPPO] observe moderate to significant performance gain of 8%~27.8% over benchmark when model size > 10M parameters.

where the model size (# parameters) is the average of the encoder size and the decoder size.

Comparison between Case0 and Case2 in terms of complexity vs performance:

A graph with numbers and dots

AI-generated content may be incorrect.

A close-up of a graph

AI-generated content may be incorrect.

In summary,

· Temporal domain Case 2 can achieve higher gain compared to Case 0 with similar or increased complexity

o Some companies achieved gain using Case 2 AI/ML models having same/similar/lower complexity as their Case 0 AI/ML models, while some other companies achieved gain using Case 2 AI/ML models having higher complexity than their Case 0 AI/ML models.

· Note: The Case 2 evaluations for this summary were done under no UCI loss.

Observation

Case 3, model complexity (FLOPs) vs. SGCS gain (%)

A graph with different colored dots

AI-generated content may be incorrect.

For temporal domain Case 3, the results on trade-off between complexity (FLOPs) and SGCS gain (%) over benchmark (Rel-18 doppler eType II) are summarized as follows

· For layer1,

o 1 source [Ericsson] observes performance gain of 4.22% over benchmark when FLOPs <= 10M.

o 8 sources [Ericsson, CMCC, QC, DCM, ZTE, CATT, Vivo, MTK] observe minor to significant performance gain of 2.4%~28% over benchmark when 10M< FLOPs <= 100M.

o 4 sources [Fujitsu, Xiaomi, InterDigital, OPPO] observe minor to significant performance gain of -4%~39.76% over benchmark when FLOPs > 100M.

where the complexity (FLOPs) is the average of the encoder FLOPs and the decoder FLOPs.

Case 3, model size (# parameters) vs. SGCS gain (%)

A graph with numbers and symbols

AI-generated content may be incorrect.

For temporal domain Case 3, the results on trade-off between model size (# parameters) and SGCS gain (%) over benchmark (Rel-18 doppler eType II) are summarized as follows

· For layer1,

o 4 sources [QC, Ericsson, CATT, DCM] observe minor to significant performance gain of 3.9%~22% over benchmark when model size <= 1M parameters.

o 7 sources [InterDigital, Ericsson, Vivo, Fujitsu, MTK, ZTE, CMCC] observe minor to significant performance gain of -4%~16.6% over benchmark when 1M< model size <= 10M parameters.

o 2 sources [Xiaomi, OPPO] observe significant performance gain of 20.8%~39.76% over benchmark when model size > 10M parameters.

where the model size (# parameters) is the average of the encoder size and the decoder size.

Comparison between Case0 and Case3 in terms of complexity vs performance:

· Note 1: Case 0 gain is w.r.t. Rel-16 eType II benchmark, in scenario of mixed indoor and outdoor

· Note 2: Case 3 gain is w.r.t. Rel-18 Doppler eType II benchmark, in scenario of mixed indoor and outdoor, or outdoor only

A graph with numbers and a chart

AI-generated content may be incorrect.

In summary,

· Under CSI prediction, temporal domain Case 3 can achieve better performance than Rel-18 Doppler eType II benchmark. The amount of gain of Case 3 over Rel-18 Doppler eType II benchmark is similar to the amount of gain of Case 0 over Rel-16 eType II.

· On average, for each inference, FLOPs of Case 3 is higher than that of Case 0.

Agreement

Replace the following figure in the agreed observation

A graph with numbers and dots

AI-generated content may be incorrect.

with the following figure.

A graph with blue and green dots

AI-generated content may be incorrect.

Observation

Localized models, model complexity (FLOPs) and model size (# parameters) vs. SGCS gain (%)

Based on the evaluations results in table X3 (Typo correction: Layer 0 in plot 2 needs to be corrected to Layer 1)

A graph of a number of red and blue dots

AI-generated content may be incorrect.

A graph with red and blue dots

AI-generated content may be incorrect.

For localized models,

· 5 sources [ZTE, Vivo, Oppo, Intel, Fujitsu] observed that local models can improve the complexity-performance trade-off compared to global models.

Agreement

For inter-vendor collaboration, RAN1 concludes that both Direction A and Direction C are feasible. For Direction A, RAN1 concludes that the feasible sub-options are sub-option 4-1 and sub-option 3a-1, and in case of sub-option 3a-1, with and without target CSI sharing from NW side.

Performance: Direction C with standardized reference model (structure + parameters) ensures a minimum performance requirement, while Direction A with standardized reference model structure + parameters (sub-option 3a-1), or standardized dataset exchange (sub-option 4-1) from NW-side to UE-side may achieve better performance.
Direction C addresses inter-vendor collaboration complexity: From RAN1 perspective, Direction C (a.k.a., option 1) eliminates the inter-vendor collaboration complexity if it is feasible to standardize the model. The fully standardized reference model (structure + parameters) should be trained using synthetic data. The model structure and parameters are assumed to be equivalent to the to-be-specified model, if specified, for performance requirements in RAN4. RAN1 concludes that the scalable model structure specification and model parameters specification is feasible, but the conclusion on interoperability and RAN4 testing feasibility is a separate study in RAN4.
For Direction A with sub-option 4-1 and 3a-1, RAN1 concludes that standardized signaling, if feasible and specified, can be used for model parameter / dataset exchange to alleviate / resolve the inter-vendor collaboration complexity. The standardized signaling, if needed, may be over-the-air, or other approaches. For OTA and non-OTA based standardized signaling, as well as the feasibility of standardized signaling, related status have been provided in [R2-2503169]. For sub-option 3a-1, the specified encoder (a.k.a., CSI generation part) structure should be determined using synthetic data, and the scalable encoder structure specification is feasible.

For NW-side performance monitoring, RAN1 concludes that target CSI reporting via legacy codebooks can be used. Target CSI reporting with CSI codebook enhancement via higher-resolution parameter combination may be beneficial for improving NW-side performance monitoring with additional cost of complexity and overhead at UE side.

For UE-side side monitoring, RAN1 concludes that it is feasible, but some companies think that, at least in some UE-side monitoring options, NW-side monitoring with target CSI reporting is needed to check the reliability of UE-side monitoring reports.

NW side data collection for training is studied including data format, configuration of rank / layer, number of subbands and mechanisms for ground-truth reporting, but not all aspects are concluded. UE side data collection for training is studied including NW configuration or UE request, configuration for temporal aspects, but not all aspects are concluded. Aspects that were not concluded can be discussed in the normative phase.

The study of CSI feedback using two-sided model is complete from RAN1 perspective.

Based on the study, for addressing inter-vendor collaboration complexity, RAN1 identifies the following specification impacts for supporting sub-option 3a-1 (including with target CSI and without target CSI), sub-option 4-1, and Direction C

Reference model / structure specification (for sub-option 3a-1 and Direction C)

Note: The so called fully specified reference model discussed in RAN1 for Direction C is assumed to be equivalent to the to-be-specified model, if specified, for performance requirements in RAN4.
Note: The model structure(s) for the reference encoder in inter-vendor collaboration sub-option 3a-1 can be same as/equivalent to the structure of the RAN4 defined/specified (if defined/specified for testability) reference encoder.

To reduce the workload of the potential normative work scope, the model structure(s) for the reference encoder in inter-vendor collaboration sub-option 3a-1 is(are) same as/equivalent to the structure of the RAN4 defined/specified (if defined/specified for testability) reference encoder.

Note: RAN1 has studied and agreed on a scalable model structure for feasibility study during Rel-19 study, and considers that can serve as a starting point for the model structure specification for the potential normative work.

Format and contents of parameter/dataset/information exchange: dataset (for 4-1 and 3a-1 with target CSI)/ encoder parameter (for 3a-1) / additional information (for 3a-1 and 4-1).
The workload can be reduced by identifying the common part among different aspects.

Based on the study, RAN1 recommends the following with potential RAN1 specification impacts common to all inter-vendor collaboration options.

Recommend Case 0

Case 2 and 3 can be considered for further enhancement built upon the specification of case 0.

Recommend following specification impacts for the two-sided CSI compression use case

Model pairing procedure including ID and applicability reporting
Inference aspects including target CSI type, measurement and report configuration, CQI / RI determination, payload determination, quantization configuration / codebook, UCI mapping, CSI processing criteria and timeline, priority rules for CSI reports
NW and UE side data collection for training,

Target CSI format
Note: The framework defined in BM and CSI prediction use cases could be reused.

Specify performance monitoring, if needed

--------------------------------------- END OF TP ------------------------------------

R1-2504741 Draft summary of Additional study on AI/ML for NR air interface: CSI compression Moderator (Qualcomm)

R1-2504740 Draft summary of Additional study on AI/ML for NR air interface: CSI compression Moderator (Qualcomm)

R1-2504739 Draft summary of Additional study on AI/ML for NR air interface: CSI compression Moderator (Qualcomm)

R1-2504738 Draft summary of Additional study on AI/ML for NR air interface: CSI compression Moderator (Qualcomm)

R1-2504737 Draft summary of Additional study on AI/ML for NR air interface: CSI compression Moderator (Qualcomm)

R1-2503231 Discussion of CSI compression on AI/ML for NR air interface FUTUREWEI

R1-2503245 AI/ML for CSI compression Ericsson

R1-2503254 Discussion on AI/ML for CSI compression Huawei, HiSilicon

R1-2503350 Discussion on CSI compression vivo

R1-2503508 Discussion on AIML for CSI compression Spreadtrum, UNISOC

R1-2503553 Views on additional study for AI/ML based CSI compression Samsung

R1-2503628 Discussion on CSI compression and other aspects on AlML air interface TCL

R1-2503651 Discussion on study for AI/ML CSI compression ZTE Corporation, Sanechips

R1-2503710 Discussion on study for AI/ML CSI compression Tejas Network Limited

R1-2503728 Views on UCI loss mitigation Ofinno

R1-2503756 Discussion on Additional Study for AI/ML CSI Compression Indian Institute of Tech (M), IIT Kanpur

R1-2503773 Discussion on AI/ML-based CSI compression CATT

R1-2503823 Discussion on AI/ML for CSI compression CMCC

R1-2503875 Further discussion on remained issues for AI/ML model based CSI compression Xiaomi

R1-2503923 Discussion on CSI compression NEC

R1-2503977 On AI/ML-based CSI compression and other aspects InterDigital, Inc.

R1-2503983 Study on CSI compression LG Electronics

R1-2503989 Discussion on AI/ML for CSI compression Panasonic

R1-2503995 Additional study on AI-enabled CSI compression NVIDIA

R1-2504027 AI/ML based CSI Compression Google

R1-2504042 On AI/ML for CSI compression Lenovo

R1-2504083 Discussion on CSI compression with AI/ML Fujitsu

R1-2504115 AI/ML for CSI Compression Nokia

R1-2504132 Discussion on AI/ML for CSI compression ETRI

R1-2504226 Additional study on AI/ML-based CSI compression OPPO

R1-2504260 Additional study on AI/ML for NR air interface - CSI compression MediaTek Inc.

R1-2504311 Discussion on AI based CSI compression Apple

R1-2504387 Additional study on CSI compression Qualcomm Incorporated

R1-2504494 Discussion on AI/ML for CSI compression NTT DOCOMO, INC.

R1-2504569 Discussion on AI/ML CSI compression Continental Automotive

R1-2504587 Discussion on AI/ML-based CSI compression Pengcheng Laboratory

R1-2504624 Discussion on AI/ML based CSI compression IIT Kanpur, Indian Institute of Tech (M)